Re: Proper way to abort incorrect cherry-picking?

[Jon Seymour <jon.seymour@gmail.com>]

On Thu, Apr 29, 2010 at 5:59 AM, Eugene Sajine <euguess@gmail.com> wrote:
> 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.

> 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
>