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

Re: Proper way to abort incorrect cherry-picking?

From
Jon Seymour <jon.seymour@gmail.com>
Date
Apr 29, 2010, 00:07 UTC
Message-ID
<s2x2cfc40321004281707x50e59113t9f2ca9aea355ac5@mail.gmail.com>
In-Reply-To
<20100428233758.GA1654@progeny.tock>
On Thu, Apr 29, 2010 at 9:37 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 8 quoted lines
> Hi Jon,
>
> Jon Seymour wrote:
>
>> If you use git reset --mixed HEAD@{1} you can reset the index to
>> HEAD@{1} to reflect the pre-merge state.
>
> The HEAD doesn’t advance in a failed merge, right?

True, but I understood this issue to be that there were two cherry picks, one of which worked, one of which failed because it was out of order. Hence git reset HEAD@{1} would reset prior to the first successful (but out of order) cherry-pick.

Any way, thanks for the explaining the virtue of git reset --merge.
jon.
Previous: Jonathan NiederNext: Andreas Krey
Message 6 of 14 in “Proper way to abort incorrect cherry-picking?”
  1. Eugene SajineApr 28, 2010
  2. David BorowitzApr 28, 2010
  3. Eugene SajineApr 28, 2010
  4. Jon SeymourApr 28, 2010
  5. Jonathan NiederApr 28, 2010
  6. Jon SeymourApr 29, 2010
  7. git cherry(pick) dumps coreAndreas Krey, Apr 29, 2010
  8. Jonathan NiederApr 29, 2010
  9. Andreas KreyApr 29, 2010
  10. Jonathan NiederApr 30, 2010
  11. cherry-pick: do not dump core when iconv failsJonathan Nieder, May 8, 2010
  12. Junio C HamanoMay 8, 2010
  13. Jonathan NiederApr 28, 2010
  14. Eugene SajineApr 28, 2010

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.