1 [Mostly copied from git's SubmittingPatches]
5 - make commits of logical units
6 - check for unnecessary whitespace with "git diff --check"
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 - if you want your work included in isl.git, add a
15 "Signed-off-by: Your Name <you@example.com>" line to the
16 commit message (or just use the option "-s" when
17 committing) to confirm that you agree to the Developer's
19 - make sure that you have tests for the bug you are fixing
20 - make sure that the test suite passes after your commit
24 - use "git format-patch -M" to create the patch
25 - do not PGP sign your patch
26 - do not attach your patch, but read in the mail
27 body, unless you cannot teach your mailer to
28 leave the formatting of the patch alone.
29 - be careful doing cut & paste into your mailer, not to
31 - provide additional information (which is unsuitable for
32 the commit message) between the "---" and the diffstat
33 - if you change, add, or remove a command line option or
34 make some other user interface change, the associated
35 documentation should be updated as well.
36 - if your name is not writable in ASCII, make sure that
37 you send off a message in the correct encoding.
38 - send the patch to the development mailing list
39 (isl-development@googlegroups.co). If you use
40 git-send-email(1), please test it first by sending email