Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees

Jonathan Nieder [off-list ref] 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.