brintos

brintos / llvm-project-archived public Read only

0
0
Text · 2.2 KiB · 5a59a12 Raw
54 lines · plain
1[Mostly copied from git's SubmittingPatches]2 3	Commits:4 5	- make commits of logical units6	- check for unnecessary whitespace with "git diff --check"7	  before committing8	- do not check in commented out code or unneeded files9	- the first line of the commit message should be a short10	  description and should skip the full stop11	- the body should provide a meaningful commit message, which12	  includes motivation for the change, and contrasts13	  its implementation with previous behaviour14	- the lines of this body should have at most 76 columns15	- if you want your work included in isl.git, add a16	  "Signed-off-by: Your Name <you@example.com>" line to the17	  commit message (or just use the option "-s" when18	  committing) to confirm that you agree to the Developer's19	  Certificate of Origin20	- make sure that you have tests for the bug you are fixing21	- make sure that the test suite passes after your commit22 23	Patch:24 25	- use "git format-patch -M" to create the patch26	- do not PGP sign your patch27	- send a single patch per mail, e.g., using git-send-email(1)28	- do not attach your patch, but read in the mail29	  body, unless you cannot teach your mailer to30	  leave the formatting of the patch alone.31	- be careful doing cut & paste into your mailer, not to32	  corrupt whitespaces.33	- provide additional information (which is unsuitable for34	  the commit message) between the "---" and the diffstat35	- if you change, add, or remove a command line option or36	  make some other user interface change, the associated37	  documentation should be updated as well.38	- if your name is not writable in ASCII, make sure that39	  you send off a message in the correct encoding.40	- send the patch to the development mailing list41	  (isl-development@googlegroups.com).  If you use42	  git-send-email(1), please test it first by sending email43	  to yourself.44 45	Revisions:46 47	- add the revision number inside square brackets to48	  the subject line (e.g., use --subject-prefix='PATCH v2'49	  when creating the patch)50	- recall the major issues discovered during the previous51	  review and explain how you addressed them or why you52	  disagree.  Do so either in a cover letter, between the53	  "---" and the diffstat or in a separate message.54