On Friday 22 October 2010, Jonathan Nieder wrote: > 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. Ah, sorry for the misunderstanding. > > 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'. Yes, that makes sense to me, especially if we make a 'git merge --abort' synonym. Alternatively, we can make 'git merge --abort' check for MERGE_HEAD, and then defer to 'git reset --merge', while leaving 'git reset --merge' as-is. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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