On Tue, May 23, 2023 at 10:32 AM Tao Klerks via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > From: Tao Klerks <tao@xxxxxxxxxx> > > Cherry-pick, like merge or rebase, refuses to run when there are changes > in the index. However, if a cherry-pick sequence is requested, this > refusal happens "too late": when the cherry-pick sequence has already > started, and an "--abort" or "--quit" is needed to resume normal > operation. > > Normally, when an operation is "in-progress" and you want to go back to > where you were before, "--abort" is the right thing to run. If you run > "git cherry-pick --abort" in this specific situation, however, your > staged changes are destroyed as part of the abort! Generally speaking, > the abort process assumes any changes in the index are part of the > operation to be aborted. > > Add an earlier check in the cherry-pick sequence process to ensure that > the index is clean, reusing the already-generalized method used for > rebase. Also add a test. > > Signed-off-by: Tao Klerks <tao@xxxxxxxxxx> > --- My apologies for the premature submission: I've now realized I used the wrong existing check. "git rebase" checks for a clean *worktree* (ignoring untracked files), and that is what I reused here. What git merge and git cherry-pick check for, and what I should have added a check for here, is a clean *index*. 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. Tao
