On Wed, Apr 28, 2010 at 12:38, Eugene Sajine <euguess@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html