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
