archive, summarize the relevant points of the discussion.
-(3) Generate your patch using git tools out of your commits.
+(3) Generate your patch using Git tools out of your commits.
-git based diff tools generate unidiff which is the preferred format.
+Git based diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
(4) Sending your patches.
-People on the git mailing list need to be able to read and
+People on the Git mailing list need to be able to read and
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
You often want to add additional explanation about the patch,
other than the commit message itself. Place such "cover letter"
-material between the three dash lines and the diffstat.
+material between the three dash lines and the diffstat. Git-notes
+can also be inserted using the `--notes` option.
Do not attach the patch as a MIME attachment, compressed or not.
Do not let your e-mail client send quoted-printable. Do not let
identify them), to solicit comments and reviews.
After the list reached a consensus that it is a good idea to apply the
-patch, re-send it with "To:" set to the maintainer and "cc:" the
-list for inclusion.
+patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the
+list [*2*] for inclusion.
Do not forget to add trailers such as "Acked-by:", "Reviewed-by:" and
"Tested-by:" lines as necessary to credit people who helped your
patch.
+ [Addresses]
+ *1* The current maintainer: gitster@pobox.com
+ *2* The mailing list: git@vger.kernel.org
+
(5) Sign your work
To improve tracking of who did what, we've borrowed the
"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around. Although core GIT is a lot
+that are being emailed around. Although core Git is a lot
smaller project it is a good discipline to follow it.
The sign-off is a simple line at the end of the explanation for
Signed-off-by: Random J Developer <random@developer.example.org>
-This line can be automatically added by git if you run the git-commit
+This line can be automatically added by Git if you run the git-commit
command with the -s option.
Notice that you can place your own Signed-off-by: line when
tell you if your patch is merged in pu if you rebase on top of
master).
-* Read the git mailing list, the maintainer regularly posts messages
+* Read the Git mailing list, the maintainer regularly posts messages
entitled "What's cooking in git.git" and "What's in git.git" giving
the status of various proposed changes.