Home | History | Annotate | Line # | Download | only in doc 
      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 (a] 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 (a] 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.
     54