Re: [PATCH] merge-recursive: mark rename/delete conflict as unmerged

Johannes Schindelin [off-list ref] writes:

When a file was renamed in one branch, but deleted in the other, one
should expect the index to contain an unmerged entry, namely the
target of the rename.  Make it so.

That was quick, but the surrounding code makes me wonder if other
if/elseif branches also need similar handling.

For example, rename/add comes up with a new name that does not exist
anywhere, and adds both to the index; it is understandable that you need
to do this when processing a merge with non-zero depth because you need to
have a tree as the result, but shouldn't the final zero depth merge just
use the original names and leave the results in higher stages?