• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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.
53