prefix the first line with "area: " where the area is a filename or
identifier for the general area of the code being modified, e.g.
- . archive: ustar header checksum is computed unsigned
- . git-cherry-pick.txt: clarify the use of revision range notation
+ . doc: clarify distinction between sign-off and pgp-signing
+ . githooks.txt: improve the intro section
If in doubt which identifier to use, run "git log --no-merges" on the
files you are modifying to see the current conventions.
+It's customary to start the remainder of the first line after "area: "
+with a lower-case letter. E.g. "doc: clarify...", not "doc:
+Clarify...", or "githooks.txt: improve...", not "githooks.txt:
+Improve...".
+
The body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what is wrong
without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.
+If you want to reference a previous commit in the history of a stable
+branch, use the format "abbreviated sha1 (subject, date)",
+with the subject enclosed in a pair of double-quotes, like this:
+
+ Commit f86a374 ("pack-bitmap.c: fix a memleak", 2015-03-30)
+ noticed that ...
+
+The "Copy commit summary" command of gitk can be used to obtain this
+format, or this invocation of "git show":
+
+ git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit>
(3) Generate your patch using Git tools out of your commits.
Exception: If your mailer is mangling patches then someone may ask
you to re-send them using MIME, that is OK.
-Do not PGP sign your patch, at least for now. Most likely, your
-maintainer or other people on the list would not have your PGP
-key and would not bother obtaining it anyway. Your patch is not
-judged by who you are; a good patch from an unknown origin has a
-far better chance of being accepted than a patch from a known,
-respected origin that is done poorly or does incorrect things.
+Do not PGP sign your patch. Most likely, your maintainer or other people on the
+list would not have your PGP key and would not bother obtaining it anyway.
+Your patch is not judged by who you are; a good patch from an unknown origin
+has a far better chance of being accepted than a patch from a known, respected
+origin that is done poorly or does incorrect things.
If you really really really really want to do a PGP signed
patch, format it as "multipart/signed", not a text/plain message
*2* The mailing list: git@vger.kernel.org
-(5) Sign your work
+(5) Certify your work by adding your "Signed-off-by: " line
To improve tracking of who did what, we've borrowed the
"sign-off" procedure from the Linux kernel project on patches