Re: New Git hooks for checking file names in commit messages

[Jim Porter <jporterbugs@gmail.com>]

On 4/21/2023 5:05 AM, John Yates wrote:
> On Fri, Apr 21, 2023 at 12:55 AM Jim Porter <jporterbugs@gmail.com> wrote:
>>
>> This also means that if you want to use a "*" for a bulleted list of
>> sentences, you should do something to make it not look like a file
>> entry. For example, " *" is ok.
> 
> I am not wild about this change in commit message syntax.  It clashes
> with all my other uses of git.

It's not a change in syntax (at least, it's not *intended* to change the 
syntax). Commit messages for Emacs should all use the GNU Changelog 
format so that they can be imported into the actual ChangeLog files. 
These then get used to update etc/AUTHORS via the admin/authors.el 
script, which looks at the file entries in the ChangeLog files.[1]

This ended up being a problem for Eli when preparing the Emacs 29 
prerelease tarball, since there were a bunch of incorrect commit 
messages that required several hours of manual intervention to fix. 
(Since I was one of the people Eli emailed off-list to inform us that 
we'd made these errors, I thought I should take some time to help 
prevent this issue in the future.)

I tried to be as lenient as possible with the Git hooks so that they 
only catch things that would be a problem for admin/authors.el, though
there are some small differences regarding multi-line lists of files.

> Do you allow more than one file on a bulleted line?

Yes. admin/authors.el allows this, so the Git hooks also allow it. (I 
don't personally like it though.)

In principle, we could copy over the admin/authors.el heuristic though: 
a line beginning with "*" starts a file entry *only if there's a ":" 
somewhere following it, up to the next whitespace-only line*. This would 
help avoid some false positives, but it also fails to catch errors where 
committers forgot to add the ":", which I saw on several occasions when 
looking over historical commits.

[1] That's a bit indirect (you could update etc/AUTHORS from the git 
logs directly), but it lets maintainers modify the ChangeLog if 
necessary before updating etc/AUTHORS, e.g. to fix authorship of a 
change or to remove entries if they were backed out for some reason.