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

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:

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

But somehow I got underwhelming responses.

I further think the "WARNING: " below is needlessly eating one
extra line of screen real estate without any additional value.

If one tree renamed a file (and creating the same or similar
file in another location) while the other tree kept the file
intact, then we would see "Removing $4" from the "deleted in one
and unchanged in the other" (and corresponding "Adding $4 with
perm $mode" for the rename destination).  If the user wants to
be careful about renames then all "Removing ..." need to be
examined _anyway_.  I would think it would be saner to collapse
these two case arms to catch "$1.." | "$1.$1" | "$1$1."  pattern
and just say "Removing $4".

    case "${1:-.}${2:-.}${3:-.}" in
    #
    # Deleted in both.
    #
    "$1..")
            echo "WARNING: $4 is removed in both branches."
            echo "WARNING: This is a potential rename conflict."
            rm -f -- "$4" &&
                    exec git-update-cache --remove -- "$4"
            ;;

    #
    # Deleted in one and unchanged in the other.
    #
    "$1.$1" | "$1$1.")
            echo "Removing $4"
            exec rm -f -- "$4" &&
                    git-update-cache --remove -- "$4"
            ;;