Subject: Re: git merge --abort? [was: Re: [PATCHv4 00/21] git notes merge]

From: Jonathan Nieder <[email-masked]>
Date: Fri, 22 Oct 2010 09:55:53 -0500

Johan Herland wrote:

> Does this mean that there are situations where you simply _cannot_ get 
> back to the pre-merge state (using 'git reset --merge' or otherwise)?

Technically yes, there is such an edge case, but I don't think that
was what he was talking about.

> Is this something we should detect and warn about when starting the 
> merge? Something like:
> 
>   $ git merge bar
>   I'm sorry, Dave. I'm afraid I can't merge with and unclean index.
>   Use -f to force the merge anyway, but then 'git merge --abort' will
>   lose your staged changes.

"Use -f to force the merge anyway" does not make sense to me.
git merge does not work with an index that does not match HEAD (except
in the aforementioned edge case where the content in the edge already
matches the merged content).  So 'git merge' bails out in this case,
leaving the index as-is; if a person doesn't notice that and tries
'git reset --merge', her staged changes may be clobbered.

> Or could we solve it simply by making a backup of the pre-merge index 
> that can later be restored by 'git merge --abort'?

Yes, that's one way.  I think it might be better for 'git reset
--merge' to check for MERGE_HEAD and do nothing if it is absent if we
want it to be closer to an inverse to failed 'git merge'.