[cc:+peff +philip] On Fri, Jul 5, 2024 at 4:12 PM Sean Allred <allred.sean@xxxxxxxxx> wrote: > 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@xxxxxxxxx/ [2]: https://lore.kernel.org/git/m034onpng4.fsf@xxxxxxxxxxxxxxxxxx/
