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

[Jim Porter <jporterbugs@gmail.com>]

On 4/22/2023 12:03 AM, Eli Zaretskii wrote:
>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Should branches be checked by these hooks before they are merged into
>> master/version branches?
> 
> No.  We don't enforce these rules on branches from which Emacs
> tarballs will not be produced.  The commit log message which matters
> for those is the one of the merge-commit when the branch is landed on
> master.
I'll make sure this works. I do think it's useful to check commits on 
all branches, since we won't know until the merge how a committer plans 
to do the merge. For example, you could push a feature branch upstream, 
and when the time comes to merge it, rebase it onto master. In that case 
the history is linear, so we'd want to check every commit that was 
newly-added to master.

I'm not exactly sure how the Git log -> ChangeLog -> etc/AUTHORS process 
works for merge commits, but it shouldn't be too hard to make the Git 
hooks be compatible with that process. (For example, we could just 
detect if we're pushing a merge commit and then stop validating any 
commits-to-be-pushed prior to that.)

Of course, we could also say that it's still useful to validate all 
those commits anyway, since it keeps our commit history better-formatted.

If there's ever a case where these new hooks do the wrong thing, we can 
just run "git push --no-verify" to ignore the hooks. We're the humans, 
so we have the final word over the computer, after all. :)