From: Jonathan Nieder <jrnieder@gmail.com>
Date: Wed, 28 Apr 2010 23:37:58 GMT
Subject: Re: Proper way to abort incorrect cherry-picking?
Message-ID: <20100428233758.GA1654@progeny.tock>
In-Reply-To: <o2j2cfc40321004281539j28fe44e0r5d029061e3e08b90@mail.gmail.com>

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