Re: Should commit-msg hook receive the washed message?

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jul 5, 2024, 21:35 UTC
Message-ID: <CAPig+cTpxXNwy8MYWjcDTa5QPoq5Mod3_LZ=+F16-gF5QVbrkg@mail.gmail.com>
In-Reply-To: <m0h6d3pphu.fsf@epic96565.epic.com>

[cc:+peff +philip]

On Fri, Jul 5, 2024 at 4:12 PM Sean Allred <allred.sean@gmail.com> wrote:

Show 19 quoted lines

> From githooks.txt:
> > This hook is invoked by linkgit:git-commit[1] and
> > linkgit:git-merge[1], and can be bypassed with the `--no-verify`
> > option. It takes a single parameter, the name of the file that holds
> > the proposed commit log message. Exiting with a non-zero status causes
> > the command to abort.
>
> Of course the actual 'proposed commit log message' doesn't include the
> comments included when running a commit, e.g.
>
>     git -c commit.status=true commit
>
> but the execution of the `commit-msg` happens before `cleanup_message`
> is called on COMMIT_EDITMSG.
>
> This seems like a bug to me; is there something I'm missing? I would
> propose adding a call to `cleanup_message` (with the appropriate
> arguments) inside `prepare_to_commit` right before `commit-msg` is
> invoked.

The idea of calling cleanup_message() has been discussed before[1]. My takeaway from reading that message is that calling cleanup_message() unconditionally before invoking the hook could potentially throw away information that the hook might want to consult. It's possible to imagine a workflow in which a specialized comment is inserted in a commit message to control/augment behavior of the hook in some fashion.

The idea you proposed in a different thread[2] of exposing cleanup_message() functionality as a user-facing utility which a hook can call on an as-needed basis may make more sense(?).

[1]: https://lore.kernel.org/git/693954a7-af64-67c5-41b9-b648a9fe3ef2@gmail.com/ [2]: https://lore.kernel.org/git/m034onpng4.fsf@epic96565.epic.com/