Hello,
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.
Be well,
Kurt von Laven
Kurt von Laven [off-list ref] 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 ;-).
On Fri, Sep 17 2021, Junio C Hamano wrote:
Kurt von Laven [off-list ref] writes:
quoted
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 ;-).
I'd think we'd want to call it on an empty message, e.g. maybe someone
depends on that with empty message = auto-generate a message for me.
But for those that don't, doesn't the default behavior of "git commit"
catch this in either case, i.e. it wouldn't let it pass without
--allow-empty-message.
I understood this report as the hook taking the empty message (e.g. the
user using it as a shorthand to abort), and their hook "helpfully"
inserting some "default" message or template.