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 28, 2010, 22:39 UTC
Message-ID
<o2j2cfc40321004281539j28fe44e0r5d029061e3e08b90@mail.gmail.com>
In-Reply-To
<h2v76c5b8581004281259yfaca7abfz5a455ff8fd6cdc6b@mail.gmail.com>
On Thu, Apr 29, 2010 at 5:59 AM, Eugene Sajine <euguess@gmail.com> wrote:
Show 27 quoted lines
> On Wed, Apr 28, 2010 at 3:49 PM, David Borowitz <dborowitz@google.com> wrote:
>> On Wed, Apr 28, 2010 at 12:38, Eugene Sajine <euguess@gmail.com> wrote:
>>>
>>> hi,
>>>
>>> we have tried to cherry-pick 2 commits from one branch to another
>>> branch, but unfortunately the incorrect commit was chosen to be
>>> applied first.
>>>
>>> Thus, the automatic cherry-pick failed and caused conflicts, so in
>>> order to to cancel the whole operation i had to do the following:
>>>
>>> 1. mark the conflicting files as resolved (without even resolving
>>> them) by doing git add.
>>> 2. unstage all files staged for commit as a result of incomplete cherry picking
>>> 3. manually checkout touched files to their correct state (git checkout file)
>>>
>>> and then i was able to repeat cherry-picking with correct commits.
>>>
>>> Is there a better way?
>>
>> git reset --hard HEAD@{1}?
>
> not always working. In our particular case there were some local
> modifications to other files, which would be blown away with this for
> no reason. That's why I went the long way of resetting specific files.
>

If you use git reset --mixed HEAD@{1} you can reset the index to HEAD@{1} to reflect the pre-merge state. The unstaged changes will then be a combination of the failed merge and the local modifications to the files. You can then revert the changes from the merge.

Then you can use git stash to move the local modifications out of the way, then repeat the cherry pick in the correct order, then use git stash pop to reapply the local modifications to the working tree and index.

This is more complicated than it needs to be - if you had stashed (or committed) before cherry picking, things would be simpler.

jon.
Show 7 quoted lines
> Thanks,
> Eugene
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Previous: Eugene SajineNext: Jonathan Nieder
Message 4 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.