Re: On recording renames

From: Junio C Hamano <junkio@cox.net>
Date: Mar 4, 2006, 06:16 UTC
Message-ID: <7v64muvin9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vfylyx3e3.fsf@assigned-by-dhcp.cox.net>

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

Show 21 quoted lines

>
>        a1--a2--a3--a4--a5--A
>       /                     \
>   ---O---b1--b2--b3--b4--B---* 
>
>     O has hello.c
>     a1 renames file hello.c to world.c and a2-a5-A modifies world.c
>     b1-b4-B modifies hello.c 
>     we are about to merge A and B
>
>     comparing O and A may not notice O's hello.c and A's world.c
>     are similar!
>
> But you are allowed to write a new merge strategy that is more
> careful about renames.  There is no reason you can only look at
> three trees.  Such a merge strategy, when given commit A and B,
> would walk the history back, running "diff-tree -M" for each
> commit along the way, and difference between O's hello.c and
> a1's world.c would be hopefully *much* smaller than O's hello.c
> and A's world.c -- even the current similarity estimator may
> recognize it is a rename.

A bit more on merges and renames. The thread that started on Dec 16 2005 by Don Zickus is about a case that anybody interested in renaming merge should think about. Unfortunately gmane web interface says it is "down for maintenance" so I cannot give an URL, but the message IDs of key messages are:

        <68948ca0512161205x3d5921bfm3bfcaa64f988eb99@mail.gmail.com>
        <7vbqzgbcyv.fsf@assigned-by-dhcp.cox.net>

The whole thread is worth reading, but the punch line is:

        The transition happened over time with multiple commits.
        You cannot record "this is the rename" by attributing that
        information to one particular commit.