git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 6, 2016, 18:58 UTC
Message-ID
<xmqqlgvs28bh.fsf@gitster.mtv.corp.google.com>

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!
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.
 (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".
Thanks.
Next: Christian Couder
Message 1 of 15 in “BUG: "cherry-pick A..B || git reset --hard OTHER"”
  1. Junio C HamanoDec 6, 2016
  2. Christian CouderDec 7, 2016
  3. Stephan BeyerDec 7, 2016
  4. Junio C HamanoDec 7, 2016
  5. Stephan BeyerDec 7, 2016
  6. Duy NguyenDec 7, 2016
  7. Duy NguyenDec 9, 2016
  8. rebase: rename --forget to be consistent with sequencerNguyễn Thái Ngọc Duy, Dec 9, 2016
  9. revert, cherry-pick: rename --quit to be consistent with rebaseNguyễn Thái Ngọc Duy, Dec 9, 2016
  10. Junio C HamanoDec 9, 2016
  11. Stephan BeyerDec 9, 2016
  12. Stephan BeyerDec 9, 2016
  13. Duy NguyenDec 10, 2016
  14. Junio C HamanoDec 10, 2016
  15. Christian CouderDec 8, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.