Hi, On 12/06/2016 07:58 PM, Junio C Hamano wrote: > I was burned a few times with this in the past few years, but it did > not irritate me often enough that I didn't write it down. But I > think this is serious enough that deserves attention from those who > were involved. > > A short reproduction recipe, using objects from git.git that are > publicly available and stable, shows how bad it is. > > $ git checkout v2.9.3^0 > > $ git cherry-pick 0582a34f52..a94bb68397 > ... see conflict, decide to give up backporting to > ... such an old fork point. > ... the git-prompt gives "|CHERRY-PICKING" correctly. > > $ git reset --hard v2.10.2^0 > ... the git-prompt no longer says "|CHERRY-PICKING" > > $ edit && git commit -m "prelim work for backporting" > [detached HEAD cc5a6a9219] prelim work for backporting > > $ git cherry-pick 0582a34f52..a94bb68397 > error: a cherry-pick or revert is already in progress > hint: try "git cherry-pick (--continue | --quit | --abort)" > fatal: cherry-pick failed > > $ git cherry-pick --abort > ... we come back to v2.9.3^0, losing the new commit! Apart from the git-prompt bug: isn't this a user error? I think "git cherry-pick --quit"[1] would be the right thing to do, not --abort. On the other hand, one (as a user) could also expect that "git reset --hard" also resets sequencer-related states (and that is what the git-prompt suggests), but that would probably break a lot of scripts ;) [1] By the way: git cherry-pick --quit, git rebase --forget ... different wording for the same thing makes things unintuitive. > (1) The third invocation of "cherry-pick" with "--abort" to get rid > of the state from the unfinished cherry-pick we did previously > is necessary, but the command does not notice that we resetted > to a new branch AND we even did some other work there. This > loses end-user's work. > > "git cherry-pick --abort" should learn from "git am --abort" > that has an extra safety to deal with the above workflow. The > state from the unfinished "am" is removed, but the head is not > rewound to avoid losing end-user's work. > > You can try by replacing two instances of > > $ git cherry-pick 0582a34f52..a94bb68397 > > with > > $ git format-patch --stdout 0582a34f52..a94bb68397 | git am > > in the above sequence, and conclude with "git am--abort" to see > how much more pleasant and safe "git am --abort" is. Definitely. I'd volunteer to add that safety guard. (But (2) remains.) ~Stephan