Grégoire PARIS [off-list ref] 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.
Le 03/03/2016 23:55, Junio C Hamano a écrit :
Grégoire PARIS [off-list ref] writes:
quoted
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.
Sorry for top-posting, I'll keep in mind to not do this.
You're describing very precisely how using cherry-pick --continue makes
me feel. I checked again right now and even though there is a comment to
make me understand that commit would do a great job at solving my
problem (hint: and commit the result with 'git commit'), I failed to
notice it.
I agree with you, adding every commit option is not a good solution…
Maybe a good solution would be to display a special message when using
cherry-pick --continue with unrecognized options? Like for instance
> hint: try git commit --no-verify, then git cherry-pick --continue to
replay the next commit
What do you think?
--
greg0ire