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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux