Re: Proper way to abort incorrect cherry-picking?

On Wed, Apr 28, 2010 at 12:38, Eugene Sajine [off-list ref] 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}?

Shouldn't there be a "git cherry-pick --abort"
for such cases as it exists for rebase?

ISTM the --abort flag to rebase is useful because HEAD may have
changed an arbitrary number of times between the start of the rebase
and now, so you wouldn't know which reflog entry to choose. (The same
holds for "git bisect reset".) But with a cherry-pick it's always
@{1}.

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