Re: Proper way to abort incorrect cherry-picking?

Hi Jon,

Jon Seymour wrote:

If you use git reset --mixed HEAD@{1} you can reset the index to
HEAD@{1} to reflect the pre-merge state.

The HEAD doesn’t advance in a failed merge, right?

[...]

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

If this were really necessary, I would consider it a bug.

I do think recovery is more complicated than it needs to be, since one
has to check whether the merge/cherry-pick failed before cancelling
it.  There are three cases.

 - If an early check prevented the operation (message with “fatal:”,
   status = 128), then the index and work tree were not touched.

   No recovery required.

 - If there were conflicts (message with “Conflicts:”, status = 1),
   the index will record the competing versions of conflicted files,
   and the work tree will represent the situation with conflict
   markers.

   Use ‘git reset --merge’ to recover.

 - If the merge proceeded cleanly (status = 0), but it was a bad
   idea after all, the index and work tree record the new version now.

   Use ‘git reset --keep HEAD@{1}’ to undo the operation.

Have fun,
Jonathan