threads / rfc / 864

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

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

## tl;dr

2 messages between Jun 8, 2005 and Jun 9, 2005.

replies: 1people: 1as markdown or json

Junio C Hamano· Jun 8, 2005, 17:21 UTC · lore

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.

Junio C Hamano· Jun 9, 2005, 00:34 UTC · re: Junio C Hamano · lore

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

>>>>> "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"
            ;;

← back to recent threads