doc/SubmittingPatches

   1 [Mostly copied from git's SubmittingPatches]
   2
   3         Commits:
   4
   5         - make commits of logical units
   6         - check for unnecessary whitespace with "git diff --check"
   7           before committing
   8         - do not check in commented out code or unneeded files
   9         - the first line of the commit message should be a short
  10           description and should skip the full stop
  11         - the body should provide a meaningful commit message, which
  12           includes motivation for the change, and contrasts
  13           its implementation with previous behaviour
  14         - the lines of this body should have at most 76 columns
  15         - if you want your work included in isl.git, add a
  16           "Signed-off-by: Your Name <you@example.com>" line to the
  17           commit message (or just use the option "-s" when
  18           committing) to confirm that you agree to the Developer's
  19           Certificate of Origin
  20         - make sure that you have tests for the bug you are fixing
  21         - make sure that the test suite passes after your commit
  22
  23         Patch:
  24
  25         - use "git format-patch -M" to create the patch
  26         - do not PGP sign your patch
  27         - send a single patch per mail, e.g., using git-send-email(1)
  28         - do not attach your patch, but read in the mail
  29           body, unless you cannot teach your mailer to
  30           leave the formatting of the patch alone.
  31         - be careful doing cut & paste into your mailer, not to
  32           corrupt whitespaces.
  33         - provide additional information (which is unsuitable for
  34           the commit message) between the "---" and the diffstat
  35         - if you change, add, or remove a command line option or
  36           make some other user interface change, the associated
  37           documentation should be updated as well.
  38         - if your name is not writable in ASCII, make sure that
  39           you send off a message in the correct encoding.
  40         - send the patch to the development mailing list
  41           (isl-development@googlegroups.com).  If you use
  42           git-send-email(1), please test it first by sending email
  43           to yourself.
  44
  45         Revisions:
  46
  47         - add the revision number inside square brackets to
  48           the subject line (e.g., use --subject-prefix='PATCH v2'
  49           when creating the patch)
  50         - recall the major issues discovered during the previous
  51           review and explain how you addressed them or why you
  52           disagree.  Do so either in a cover letter, between the
  53           "---" and the diffstat or in a separate message.