| Tobias Grosser | 52a2523 | 2015-02-04 20:55:43 +0000 | [diff] [blame] | 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 | - 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 |
| 18 | Certificate of Origin |
| 19 | - make sure that you have tests for the bug you are fixing |
| 20 | - make sure that the test suite passes after your commit |
| 21 | |
| 22 | Patch: |
| 23 | |
| 24 | - use "git format-patch -M" to create the patch |
| 25 | - do not PGP sign your patch |
| 26 | - send a single patch per mail, e.g., using git-send-email(1) |
| 27 | - do not attach your patch, but read in the mail |
| 28 | body, unless you cannot teach your mailer to |
| 29 | leave the formatting of the patch alone. |
| 30 | - be careful doing cut & paste into your mailer, not to |
| 31 | corrupt whitespaces. |
| 32 | - provide additional information (which is unsuitable for |
| 33 | the commit message) between the "---" and the diffstat |
| 34 | - if you change, add, or remove a command line option or |
| 35 | make some other user interface change, the associated |
| 36 | documentation should be updated as well. |
| 37 | - if your name is not writable in ASCII, make sure that |
| 38 | you send off a message in the correct encoding. |
| 39 | - send the patch to the development mailing list |
| 40 | (isl-development@googlegroups.com). If you use |
| 41 | git-send-email(1), please test it first by sending email |
| 42 | to yourself. |
| 43 | |
| 44 | Revisions: |
| 45 | |
| 46 | - add the revision number inside square brackets to |
| 47 | the subject line (e.g., use --subject-prefix='PATCH v2' |
| 48 | when creating the patch) |
| 49 | - recall the major issues discovered during the previous |
| 50 | review and explain how you addressed them or why you |
| 51 | disagree. Do so either in a cover letter, between the |
| 52 | "---" and the diffstat or in a separate message. |