Re: BUG: "cherry-pick A..B || git reset --hard OTHER"

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 7, 2016, 14:31 UTC
Message-ID: <CAP8UFD32PcT4XgnRFaP-St3i1D-6XG1wY6qKn3bgWPKn1Y4Qwg@mail.gmail.com>
In-Reply-To: <xmqqlgvs28bh.fsf@gitster.mtv.corp.google.com>

On Tue, Dec 6, 2016 at 7:58 PM, Junio C Hamano <gitster@pobox.com> 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.

Yeah, I agree that we should do something about it.

Show 47 quoted lines

> 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!
>
> The above shows two bugs.
>
>  (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.

Ok I will try to take a look at that next week.

Show 6 quoted lines

>  (2) The bug in "cherry-pick --abort" is made worse because the
>      git-completion script seems to be unaware of $GIT_DIR/sequencer
>      and stops saying "|CHERRY-PICKING" after the step to switch to
>      a different state with "git reset --hard v2.10.2^0".  If the
>      prompt showed it after "git reset", the end user would have
>      thought twice before starting the "prelim work".

I am not used to hacking the prompt or completion scripts, so I would appreciate if someone else could do it.

Thanks, Christian.