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

[Jim Porter <jporterbugs@gmail.com>]

On 4/21/2023 11:11 PM, Eli Zaretskii wrote:
>> Date: Fri, 21 Apr 2023 10:44:10 -0700
>> From: Jim Porter <jporterbugs@gmail.com>
>> Cc: emacs-devel@gnu.org, eliz@gnu.org
>>
>> Eli, what do you think? I've run this against the 5000 latest commits
>> and the results look right (though I haven't looked as thoroughly as
>> last time).
> 
> I think the hooks should follow the GNU Standards (which are also our
> conventions), not their particular expressions in algorithms used by
> authors.el.

I *think* in this case, the two are the same... or at least the relevant 
algorithms in authors.el are consistent with the GNU standards. I don't 
see a strict set of rules in the GNU standards, so I had to make some 
guesses based on the examples and the implementation in authors.el. This 
is what I used:

1. A file entry is introduced by a line starting with "*" or ";[ \t]+*" 
(this is slightly different from authors.el; indenting the "*" will make 
it not count as a file entry for the purposes of the hooks)

2. A file entry must also contain a ":" before the next blank line

3. A file entry's list of files starts after the leading "*" and 
continues up until the first ":", "(", "[", or "<"

4. Each file in a list of files is split by spaces, and possibly a comma 
(specifically ",?[ \t]+")[1]

5. You can continue long file names over multiple lines if necessary

I think the first 3 are all consistent with the spirit of the GNU 
standards as well as all the provided examples. The 4th rule is more 
questionable; maybe we should be stricter about this one, but I saw that 
style a dozen or so times in looking through the commit history, and 
authors.el is ok with it. The last rule only comes up rarely, but it's 
useful for deeply-nested files (mostly test resources).

[1] Note: I tweaked this since the patch I posted. That's the only 
change though.