Re: Proper way to abort incorrect cherry-picking?

On Thu, Apr 29, 2010 at 5:59 AM, Eugene Sajine [off-list ref] wrote:

On Wed, Apr 28, 2010 at 3:49 PM, David Borowitz [off-list ref] wrote:

quoted

On Wed, Apr 28, 2010 at 12:38, Eugene Sajine [off-list ref] wrote:

quoted

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