From: Junio C Hamano <gitster@pobox.com>
To: Kurt von Laven <kurt.von.laven@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Don't Call commit-msg Hooks With Empty Commit Messages
Date: Fri, 17 Sep 2021 02:42:00 -0700 [thread overview]
Message-ID: <xmqqlf3vilnb.fsf@gitster.g> (raw)
In-Reply-To: CAO-Ogzs7vCtfgjZqp+cg1ERiu3bSwZM47arHJyyTrEqAQ=ZLcw@mail.gmail.com
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 ;-).
next prev parent reply other threads:[~2021-09-17 9:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 3:37 Don't Call commit-msg Hooks With Empty Commit Messages Kurt von Laven
2021-09-17 9:42 ` Junio C Hamano [this message]
2021-09-17 19:27 ` Ævar Arnfjörð Bjarmason
2021-09-17 19:43 ` Junio C Hamano
2021-09-18 9:58 ` Kurt von Laven
2021-09-19 5:06 ` Kurt von Laven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlf3vilnb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kurt.von.laven@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).