[RFC] rename/rename conflicts: do they matter?

[Junio C Hamano <junkio@cox.net>]

I was reviewing git-merge-one-file-script, and started
thinking...

It currently has a logic that says if both branches deleted the
same file, instead of taking that as a concensus to remove it,
it refuses to merge the path.  The error message states "This is a
potential rename conflict." as the rationale for doing so.  It
is trying to be careful about one branch renaming the file to
something while the other renaming it to something else.

However, it happily deletes "deleted in one and unchanged in the
other".  If we are so careful about "rename/rename conflicts", I
would think it would make more sense to be careful to consider
the possibility that one branch renamed this file, thereby
creating a copy at another path, while the other branch kept it
intact (the other side of this operation is "added in one"), but
we do not seem to bother worrying about it.  If we try to be
anal about this, then even a simple "added in one" case could
trigger "copy/copy" conflict.

My current thinking is that the current logic for "both delete"
is too anal, and we should treat this case just like other
"concensus" cases; simply removing the path in this case would
be better.