I asked this question on StackOverflow and got an answer:
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
>> 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
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.