Re: Bypassing hooks while cherry-picking

> Grégoire PARIS <postmaster@greg0ire.fr> writes:
>
>> Not sure how cherry-picking is managed, and whether commit is able to
>> see that we are doing a cherry-pick, and end it up properly. Anyway,
>> with Kevin's patch, we should be able to happily use cherry-pick
> [Please do not top post]
>
> It is somewhat sad to see such a response as that is backwards.
>
> "cherry-pick --continue" originally was "I am done with the commit I
> was asked to deal with, so please replay the next one", and in order
> to "be done with" the commit, you would used "git commit" yourself,
> with whatever necessary options (e.g. --no-verify, -s, -c) you want
> to affect the behaviour of the "git commit".
>
> It is a later invention that "cherry-pick --continue" additionally
> creates a commit when the user, even though she claims to "be done
> with", hasn't actually made the commit before going on to replay the
> next one.  It was accepted as a short-cut as most of the time you do
> not give any option to your "git commit" invocation, but probably
> was a misguided invention--it made new people somehow think that
> they are not allowed to run "git commit" to conclude the conflict
> resolution, when in reality that is an acceptable and primary way
> to do so and "--continue" is a mere short-hand.
>
> As "git commit" does have options other than "--no-verify" that
> affects the way it behaves, and can gain more such options in the
> future, having to keep adding corresponding options to "cherry-pick
> --continue --more-options" will not be a good solution in the longer
> run.
>
>