Skip to content

Commit cdba029

Browse files
committed
SubmittingPatches: explain why we care about log messages
Extend the "describe your changes well" section to cover whom we are trying to help by doing so in the first place. Signed-off-by: Junio C Hamano <[email protected]>
1 parent 607817a commit cdba029

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

Documentation/SubmittingPatches

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -110,6 +110,35 @@ run `git diff --check` on your changes before you commit.
110110
[[describe-changes]]
111111
=== Describe your changes well.
112112

113+
The log message that explains your changes is just as important as the
114+
changes themselves. Your code may be clearly written with in-code
115+
comment to sufficiently explain how it works with the surrounding
116+
code, but those who need to fix or enhance your code in the future
117+
will need to know _why_ your code does what it does, for a few
118+
reasons:
119+
120+
. Your code may be doing something differently from what you wanted it
121+
to do. Writing down what you actually wanted to achieve will help
122+
them fix your code and make it do what it should have been doing
123+
(also, you often discover your own bugs yourself, while writing the
124+
log message to summarize the thought behind it).
125+
126+
. Your code may be doing things that were only necessary for your
127+
immediate needs (e.g. "do X to directories" without implementing or
128+
even designing what is to be done on files). Writing down why you
129+
excluded what the code does not do will help guide future developers.
130+
Writing down "we do X to directories, because directories have
131+
characteristic Y" would help them infer "oh, files also have the same
132+
characteristic Y, so perhaps doing X to them would also make sense?".
133+
Saying "we don't do the same X to files, because ..." will help them
134+
decide if the reasoning is sound (in which case they do not waste
135+
time extending your code to cover files), or reason differently (in
136+
which case, they can explain why they extend your code to cover
137+
files, too).
138+
139+
The goal of your log message is to convey the _why_ behind your
140+
change to help future developers.
141+
113142
The first line of the commit message should be a short description (50
114143
characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
115144
and should skip the full stop. It is also conventional in most cases to

0 commit comments

Comments
 (0)