Re: Mistakes in commit log messages

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Apr 15, 2023 at 10:15:19 +0300, Eli Zaretskii wrote:
> > Date: Fri, 14 Apr 2023 22:45:44 -0700
> > From: Jim Porter <jporterbugs@gmail.com>
> > Cc: acm@muc.de, emacs-devel@gnu.org

> > There's also one more commit I'm not quite sure what to do about: 
> > 0a95a81d8d36722ccf030a6194ecd953fc257a59. It has this in the commit message:

> >      This fixes bug #61144.  If the space around the * is "symmetric" we 
> > leave foo
> >      * bar unfontified, a multiplication operation.  If it is 
> > "asymmetric" we
> >      fontify it as a pointer declaration.

> > The second line of this excerpt is treated like a file entry. Maybe our 
> > hook could allow that if it were clever enough, or maybe this is a rare 
> > enough occurrence that we should just have committers reformat the 
> > message slightly.

> The latter, IMO.  There's absolutely no reason for a log message to
> have a '*' as the first non-whitespace character of a line.  Fixing
> that is easy.

It can happen easily as a result of filling.  I think it would be good if
one of Jim's scripts flagged it up as an error.  What is less easy than
it might be, is correcting an erroneous commit message and submitting the
commit again using this correction.  The erroneous message remains in
..../.git/COMMIT_EDITMSG but I'm not sure how to get it back into one's
editor at the next commit attempt.  Maybe the error message could give
some help, here.

> Btw, Alan, this is a good example of your log messages, which are
> filled using a much larger value of fill-column that the default.  The
> resulting ChangeLog entries appear ugly and stand out from the rest.
> Would you please adjust your customizations to use a smaller
> fill-column value, like at most 76, when writing commit log messages?

I've been using a fill-column of 78, to match the maximum allowed width.
I'll try cutting that down to 63, as recommended in CONTRIBUTE.

-- 
Alan Mackenzie (Nuremberg, Germany).