Tao Klerks <tao@xxxxxxxxxx> writes: > The current implementation of this patch is far too restrictive. It > doesn't break any tests (and maybe I should add one now that I know), > but it's doing the wrong thing. I am ambivalent. What do we want to see in a multi-pick sequence that is different from rebase? A single-step cherry-pick can fail safely before it touches the index or the working tree files, but if two-step cherry-pick, whose first step succeeds, finds that it cannot safely carry out its second step without clobbering the local changes made to the working tree files, what should happen? Are we OK if we stopped in the state just after the first step has already been done? My (tentative) answer to that question is "yes", but the recovery options of "cherry-pick" may want to work differently from what we have seen them traditionally do. Namely, the user accepts that the first step is already done, and stopping "cherry-pick", be it called "--abort" or something else, should just remove the sequencer state and behave as if the single-pick cherry-pick on the first step only has just finished and leave such a state in the index and the working tree. If that is what we are going to do, then it would make sense to adopt the same safety semantics we use for "git merge" and "git checkout" to ensure only that the index is clean, relying on the unpack-trees machinery that stops before clobbering a locally modified working tree files. But if we are to aim for "all-or-none" semantics people expect from aborting "git rebase", I suspect that it would be way too complicated to allow random changes in the working tree files that we may only discover to be problems after starting the sequence of replaying commits one-by-one, and "too restrictive" check may be justified. To put it differently, if it is too restrictive for multi-pick, then we would want to loosen it for "git rebase" as well, as the issues are likely to be the same. Thanks.
