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
--
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