On Thu, Jan 27, 2022 at 11:02:59AM -0800, Junio C Hamano wrote: > > 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@xxxxxxxxx> > --- > Documentation/SubmittingPatches | 29 +++++++++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index 7225a0fb52..a6121d1d42 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -110,6 +110,35 @@ run `git diff --check` on your changes before you commit. > [[describe-changes]] > === 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. > + This is pretty compelling. Is it clear enough why we care about this in the commit message, as opposed to in the patch description (cover letter or post-"---" blurb)? Is it too obvious to explicitly mention that the commit message is the first thing we try to make sense of during a 'git blame' or 'git bisect'? Either way, I think this is an improvement on the doc as it was before. Reviewed-by: Emily Shaffer <emilyshaffer@xxxxxxxxxx> > 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]), > and should skip the full stop. It is also conventional in most cases to > -- > 2.35.0-177-g7d269f5170 >
