Re: Don't Call commit-msg Hooks With Empty Commit Messages

> Kurt von Laven <kurt.von.laven@gmail.com> writes:
>
>> The most common reason commit messages are left empty is to abort
>> them. commit-msg hooks that replace empty commit messages with
>> non-empty ones (i) make it impossible to abort commits, (ii) are
>> startling to developers joining a project configured in this manner,
>> and (iii) can offer no value that wouldn't be equally or better
>> offered another way. For instance, a default commit message would be
>> better implemented as a commit message template or prepare-commit-msg
>> hook. I propose that Git eventually cease calling commit-msg hooks
>> when the commit-message is empty, but I would understand if backwards
>> compatibility were the overriding concern. On the other hand, the
>> empty commit message case is easy to overlook when crafting a
>> commit-msg hook. One consequence of this behavior is that running the
>> popular pre-commit tool (https://pre-commit.com/) tends to lead to a
>> spew of false positives to the console on an aborted commit when
>> configured with commit-msg hooks.
>
> The primary reason commit-msg hook is there is *not* because we need
> a way to tweak the log message.  As you said, prepare-commit-msg and
> templates are much better way to give some sort of default.  
>
> The purpose of the hook is to serve as the gatekeeper to cause an
> attempt with a bad commit message to fail.  And a properly written
> commit-msg hook would be rejecting an empty message, instead of
> inserting cruft into an empty message file.
>
> So, from that point of view, if we were to change anything, a more
> useful thing to do might be to forbid commit-msg hook from modifying
> the file and make sure it would only verify but not modify, I
> suspect.  Doing so would have a side effect of making sure that no
> commit-msg hook will turn an empty message file into a non-empty
> message file ;-).