Re: [PATCH 3/6] revert: don't let revert continue a cherry-pick
From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:52:44
Hi again, Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:quoted
Jonathan Nieder wrote:[...]quoted
Junio explained this to me in [1]. It's very unnatural for a user to want to execute "git cherry-pick --continue" when the previous command was a "git revert": it probably means that she forgot about the in-progress "git revert".[...]I don't think that's what Junio said. Did this actually happen, or is it a theoretical worry? I think I would be more likely to run "git cherry-pick <foo>..<bar>" than "git cherry-pick --continue" if I had forgotten about an in-progress revert. The former already errors out with a sensible message. Or is the problem that I might run: git revert foo..bar git reset --merge; # conflict --- let's clean this up # ah, I remember reverting the patch that conflicted before; # let's reuse the resolution. git cherry-pick baz edit file.c; # another conflict, sigh git add file.c git cherry-pick --continue; # oops! ? That seems like a real worry, but the same problem could happen with cherry-pick used both for the multipick and single-pick, so I don't think your patch fundamentally addresses it.
Good catch. I didn't replay this scenario in my head earlier.
In other words, this is a problem caused by the overloading of the same cherry-pick command for single-pick and multi-pick. I think it should be preventable by remembering which action failed when stopping a sequence and doing only a single-pick resume if CHERRY_PICK_HEAD/REVERT_HEAD/whatever doesn't match that.
I was attempting to fix this to simplify the life of the user, not complicate it further- the user might have no idea what the next command in the sequence is, and I don't see the point in inconveniencing her. In retrospect, I think we should simply drop this patch.
What happens when there is a mixture of picks and reverts?
Permitted. -- Ram