Hi again, Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: >> Jonathan Nieder wrote: > [...] >> 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". > [...] >> [1]: http://thread.gmane.org/gmane.comp.version-control.git/185355 > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html