undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

SubmittingPatches: clarify the expected commit log description

Browse Source 
Earlier, 47afed5 (SubmittingPatches: itemize and reflect upon well written
changes, 2009-04-28) added a discussion on the contents of the commit log
message, but the last part of the new paragraph didn't make much sense.
Reword it slightly to make it more readable.

Update the "quicklist" to clarify what we mean by "motivation" and
"contrast".  Also mildly discourage external references.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Junio C Hamano 2011-03-08 16:58:19 -08:00
parent e0adb84cc6
commit d0f7dcbf42
1 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/SubmittingPatches
View File

@ -10,10 +10,18 @@ Checklist (and a short version for the impatient):
description (50 characters is the soft limit, see DISCUSSION description (50 characters is the soft limit, see DISCUSSION
in git-commit(1)), and should skip the full stop in git-commit(1)), and should skip the full stop
- the body should provide a meaningful commit message, which: - the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change", . explains the problem the change tries to solve, iow, what
not "changed" or "changes". is wrong with the current code without the change.
- includes motivation for the change, and contrasts . justifies the way the change solves the problem, iow, why
its implementation with previous behaviour the result with the change is better.
. alternate solutions considered but discarded, if any.
- describe changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed
xyzzy to do frotz", as if you are giving orders to the codebase
to change its behaviour.
- try to make sure your explanation can be understood without
external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.
- add a "Signed-off-by: Your Name <you@example.com>" line to the - add a "Signed-off-by: Your Name <you@example.com>" line to the
commit message (or just use the option "-s" when committing) commit message (or just use the option "-s" when committing)
to confirm that you agree to the Developer's Certificate of Origin to confirm that you agree to the Developer's Certificate of Origin
@ -90,7 +98,10 @@ your commit head. Instead, always make a commit with complete
commit message and generate a series of patches from your commit message and generate a series of patches from your
repository. It is a good discipline. repository. It is a good discipline.
Describe the technical detail of the change(s). Give an explanation for the change(s) that is detailed enough so
that people can judge if it is good thing to do, without reading
the actual patch text to determine how well the code does what
the explanation promises to do.
If your description starts to get too long, that's a sign that you If your description starts to get too long, that's a sign that you
probably need to split up your commit to finer grained pieces. probably need to split up your commit to finer grained pieces.
@ -99,9 +110,8 @@ help reviewers check the patch, and future maintainers understand
the code, are the most beautiful patches. Descriptions that summarise the code, are the most beautiful patches. Descriptions that summarise
the point in the subject well, and describe the motivation for the the point in the subject well, and describe the motivation for the
change, the approach taken by the change, and if relevant how this change, the approach taken by the change, and if relevant how this
differs substantially from the prior version, can be found on Usenet differs substantially from the prior version, are all good things
archives back into the late 80's. Consider it like good Netiquette, to have.
but for code.
Oh, another thing. I am picky about whitespaces. Make sure your Oh, another thing. I am picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped changes do not trigger errors with the sample pre-commit hook shipped