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