Hi Jon,

Jon Seymour wrote:

quoted text
> 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?

[...]
quoted text
> 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
--
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