Grégoire PARIS <postmas...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
