From: Junio C Hamano <junkio@cox.net>
Date: Thu, 09 Jun 2005 00:34:15 GMT
Subject: Re: [RFC] rename/rename conflicts: do they matter?
Message-ID: <7v4qc81i7s.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vll5k69y0.fsf@assigned-by-dhcp.cox.net>

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