Re: Why git-revert doesn't invoke the pre-commit and the commit-msg hooks?

From: Gustavo Chaves <gustavo@gnustavo.com>
Date: Feb 19, 2018, 14:50 UTC
Message-ID: <CAPx58qoS-J+yJ_J4QOOnKyG=EOrT5J=UoCrXfXxEijq4Z2Z_3w@mail.gmail.com>
In-Reply-To: <CAPx58qqv84+i0JbdsVzFqWB=bRDecWHxss8frD4=nWOsFj-NPg@mail.gmail.com>

I asked this question on StackOverflow and got an answer: https://stackoverflow.com/q/48852925/114983

The problem is that git-revert invokes git-commit with the -n flag, explicitly avoiding the pre-commit and the commit-msg hooks.

This was originally introduced on commit 9fa4db544e2e, by Junio Hamano, in 2005! The rationale in the commit message was the following:

>> Do not verify reverted/cherry-picked/rebased patches.

>> The original committer may have used validation criteria that is less
>> stricter than yours.  You do not want to lose the changes even if they
>> are done in substandard way from your 'commit -v' verifier's point of
>> view.

I get it, but since by default you are allowed to edit the commit message during a git-revert I think there's a case to be made to make the pre-commit and the commit-msg being invoked by default. Also, git-revert introduces new lines in the original commit message, and they could be used to trigger specific checks, such as the one I wanted to implement, to deny commits reverting merge-commits.

Shouldn't git-revert work exactly as git-commit? Instead of disabling hooks by default, it could accept the --no-verify flag just like git-commit to disable the hooks if the user wants it.

-- 
Gustavo Chaves