Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > | A merge is always between the current HEAD and one or more commits > | (usually, branch head or tag), and the index file must match the tree of > | HEAD commit (i.e. the contents of the last commit) when it starts out. In > | other words, git diff --cached HEAD must report no changes. (One exception > | is when the changed index entries are already in the same state that would > | result from the merge anyway.) > > The potentially problematic scenario for "git reset --merge" is this > last one, where a changed index entry is already in the same state > that would result from the merge. Would a "git reset --merge" reset > the changed contents away? It will discard the change, the one you independently picked up, but the change agreed with what was done by the the trash history that you are cancelling merge with. You wouldn't miss losing the same change as in that trash history. -- 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