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

[Eli Zaretskii]

> Date: Sun, 23 Apr 2023 00:19:24 -0700
> Cc: bjorn.bidar@thaodan.de, arsen@aarsen.me, acm@muc.de, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> (I forgot to reply to this part of the message previously...)
> 
> On 4/22/2023 11:11 PM, Eli Zaretskii wrote:
> > But if so, what do you want the user who does the merge do?  The log
> > messages of past commits cannot be amended, so this would simply
> > preclude people from pushing merges and/or force them to use the
> > "--no-verify" switch.  For example, a frequent situation for merges is
> > a merge from the release branch to master -- if one or more of the
> > commits being merged has bad log messages, we don't want to block the
> > merge, because nothing can be done about those bad messages at the
> > time of the merge.
> 
> I wonder if we should get rid of the pre-push hook entirely then. While 
> a committer can theoretically amend old commits prior to the merge, this 
> is messy, a lot of work, and could cause other problems too.

"git commit --amend" is not a lot of work.  I do it all the time when
applying patches by others, because they frequently have mistakes and
omissions.

> This would mean that a committer sees a warning about bad log messages 
> (at post-commit time), but it doesn't actually prevent them from doing 
> anything. A warning might be too easy to ignore, but maybe it's better 
> than being silent about it. I'm not sure what to do here...

A warning that doesn't preclude a commit from being pushed is much
less useful, IMO.