mirror of
https://github.com/git/git
synced 2024-10-28 19:25:47 +00:00
Merge branch 'jc/doc-log-messages'
Update the contributor-facing documents on proposed log messages. * jc/doc-log-messages: SubmittingPatches: explain why we care about log messages CodingGuidelines: hint why we value clearly written log messages SubmittingPatches: write problem statement in the log in the present tense
This commit is contained in:
commit
83760938bd
2 changed files with 43 additions and 0 deletions
|
@ -26,6 +26,13 @@ code. For Git in general, a few rough rules are:
|
||||||
go and fix it up."
|
go and fix it up."
|
||||||
Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
|
Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
|
||||||
|
|
||||||
|
- Log messages to explain your changes are as important as the
|
||||||
|
changes themselves. Clearly written code and in-code comments
|
||||||
|
explain how the code works and what is assumed from the surrounding
|
||||||
|
context. The log messages explain what the changes wanted to
|
||||||
|
achieve and why the changes were necessary (more on this in the
|
||||||
|
accompanying SubmittingPatches document).
|
||||||
|
|
||||||
Make your code readable and sensible, and don't try to be clever.
|
Make your code readable and sensible, and don't try to be clever.
|
||||||
|
|
||||||
As for more concrete guidelines, just imitate the existing code
|
As for more concrete guidelines, just imitate the existing code
|
||||||
|
|
|
@ -110,6 +110,35 @@ run `git diff --check` on your changes before you commit.
|
||||||
[[describe-changes]]
|
[[describe-changes]]
|
||||||
=== Describe your changes well.
|
=== Describe your changes well.
|
||||||
|
|
||||||
|
The log message that explains your changes is just as important as the
|
||||||
|
changes themselves. Your code may be clearly written with in-code
|
||||||
|
comment to sufficiently explain how it works with the surrounding
|
||||||
|
code, but those who need to fix or enhance your code in the future
|
||||||
|
will need to know _why_ your code does what it does, for a few
|
||||||
|
reasons:
|
||||||
|
|
||||||
|
. Your code may be doing something differently from what you wanted it
|
||||||
|
to do. Writing down what you actually wanted to achieve will help
|
||||||
|
them fix your code and make it do what it should have been doing
|
||||||
|
(also, you often discover your own bugs yourself, while writing the
|
||||||
|
log message to summarize the thought behind it).
|
||||||
|
|
||||||
|
. Your code may be doing things that were only necessary for your
|
||||||
|
immediate needs (e.g. "do X to directories" without implementing or
|
||||||
|
even designing what is to be done on files). Writing down why you
|
||||||
|
excluded what the code does not do will help guide future developers.
|
||||||
|
Writing down "we do X to directories, because directories have
|
||||||
|
characteristic Y" would help them infer "oh, files also have the same
|
||||||
|
characteristic Y, so perhaps doing X to them would also make sense?".
|
||||||
|
Saying "we don't do the same X to files, because ..." will help them
|
||||||
|
decide if the reasoning is sound (in which case they do not waste
|
||||||
|
time extending your code to cover files), or reason differently (in
|
||||||
|
which case, they can explain why they extend your code to cover
|
||||||
|
files, too).
|
||||||
|
|
||||||
|
The goal of your log message is to convey the _why_ behind your
|
||||||
|
change to help future developers.
|
||||||
|
|
||||||
The first line of the commit message should be a short description (50
|
The first line of the commit message should be a short description (50
|
||||||
characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
|
characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
|
||||||
and should skip the full stop. It is also conventional in most cases to
|
and should skip the full stop. It is also conventional in most cases to
|
||||||
|
@ -142,6 +171,13 @@ The body should provide a meaningful commit message, which:
|
||||||
|
|
||||||
. alternate solutions considered but discarded, if any.
|
. alternate solutions considered but discarded, if any.
|
||||||
|
|
||||||
|
[[present-tense]]
|
||||||
|
The problem statement that describes the status quo is written in the
|
||||||
|
present tense. Write "The code does X when it is given input Y",
|
||||||
|
instead of "The code used to do Y when given input X". You do not
|
||||||
|
have to say "Currently"---the status quo in the problem statement is
|
||||||
|
about the code _without_ your change, by project convention.
|
||||||
|
|
||||||
[[imperative-mood]]
|
[[imperative-mood]]
|
||||||
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
|
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
|
||||||
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
|
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
|
||||||
|
|
Loading…
Reference in a new issue