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 <gitster@pobox.com>
Junio C Hamano committed
Jan 27, 2022 at 11:02 UTC
cdba0295b0a70cf7a8113dd74be90d11ceddd5f7
1 file changed
+29
Documentation/SubmittingPatches
+29
@@ -110,6 +110,35 @@ run `git diff --check` on your changes before you commit.
110
[[describe-changes]]
111
=== Describe your changes well.
112
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
+
142
The first line of the commit message should be a short description (50
143
characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
144
and should skip the full stop. It is also conventional in most cases to