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

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

[Gustavo Chaves]

Using strace I noticed that git-revert invokes only two hooks:
- prepare-commit-msg
- post-commit

But git-commit invoke these four:
- pre-commit
- prepare-commit-msg
- commit-msg
- post-commit

Since git-revert produces a commit, why doesn't it invoke the same
hooks as git-commit?

I couldn't find any discussing about this in the list or elsewhere. So
I'm asking here.

I ended up researching this when I was implementing a hook to detect
and deny commits which revert merge-commits, since they are
troublesome (https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html).
I tried to implement it as a commit-msg hook to search for the string
"This reverts commit SHA-1" in the commit message. But git-revert
doesn't invoke the commit-msg hook.

So, for now I implemented my check as a pre-receive hook. But I find
it useful to have all pre-receive checks implemented also as a
pre-commit or a commit-msg hook so that I can detect problems at
commit time instead of only at push time.

-- 
Gustavo Chaves

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

[Gustavo Chaves]

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

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

[Phillip Wood]

Hi Gustavo

On 19/02/18 14:50, Gustavo Chaves wrote:
> 
> 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.
> 

I think you're right that cherry-pick and revert should not be passing
--no-verify when the commit message is being edited (I was surprised to
see that they were). I wonder if it's worth getting rid of the
VERIFY_MSG flag completely and just set --no-verify if EDIT_MSG isn't
set to avoid these problems in the future. I'm worried though that
someone out there is scripting with a non-interactive editor which may
break if we start verifying the message so maybe the default should be
changed and a --no-verify option added to cherry-pick and revert
instead. They'd have to change their script but at least it would work
and everyone else would get the behaviour they probably expect.

Best Wishes

Phillip

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

[Junio C Hamano]

Phillip Wood <phillip.wood@talktalk.net> writes:

> ... I'm worried though that
> someone out there is scripting with a non-interactive editor which may
> break if we start verifying the message ...

This is a very valid concern.  Making sure that 'revert' pays
attention to the --verify option when given from the command line,
without changing the default or anything else, would satisfy
everybody's wish, I would think.  It won't bother existing users,
and in addition will now give an option to people to selectively run
pre-whatever hook when they choose to.

I am not sure if we should be running pre-commit/commit-msg for
revert.  The message and the effect of revert is quite distinct from
the ordinary commit, and it is very likely that people would want to
treat them differently.  It would make more sense (if we were to add
an option to run any hook we currently do not run to the command) to
run pre-revert/revert-msg hooks instead, and then people who happen
to want to do the same thing in these hooks what they do for
ordinary commits can just call their pre-commit/commit-msg hooks
from there, perhaps.

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

[Gustavo Chaves]

2018-02-20 15:00 GMT-03:00 Junio C Hamano <gitster@pobox.com>:
> It would make more sense (if we were to add
> an option to run any hook we currently do not run to the command) to
> run pre-revert/revert-msg hooks instead, and then people who happen
> to want to do the same thing in these hooks what they do for
> ordinary commits can just call their pre-commit/commit-msg hooks
> from there, perhaps.

I like this idea very much as it doesn't break a long standing behaviour and
simply introduces a new feature.

-- 
Gustavo.