Junio C Hamano <junkio@xxxxxxx> writes:
>
> 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@xxxxxxxxxxxxxx>
<7vbqzgbcyv.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
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.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html