Re: Moved files and merges

From: H. Peter Anvin <hpa@zytor.com>
Date: Sep 5, 2005, 15:16 UTC
Message-ID: <431C6167.4070703@zytor.com>
In-Reply-To: <7vvf1gejjf.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 22 quoted lines

> 
>>  1
>> / \
>>0-2-3-5-7
>>   \   /
>>    4-6
>>
>>It shouldn't matter to the merge at 7 if the 2-3 reorganization was done 
>>locally, by applying a patch, or by merging.
> 
> 
> There was another problem in my message that treated #3
> specially.  I did it that way primarily because I wanted to have
> an algorithm that needs to look only limited (namely, one)
> number of commits, more than what we currently look at.  The
> problem is that the trail #0..#1..#3 (in the example in second
> message, whose rename probably happened between #0 and #1) may
> change the contents of the renamed file so drastically that diff
> between #2 and #3 may not look like rename anymore, while we
> could still detect it if we followed the whole trail and looked
> for renames between each commit on it.
>

One question, of course, is if one should simply keep additional metadata around to handle this sort of situations. One could, for example, keep a UUID for each file, which would be carried over by the renaming commit. If one runs into a tree which doesn't have the UUIDs, they should be generated at that time (this could be a bit tricky to do without invalidating all signatures in the tree, since the obvious way -- adding it to the tree object -- would invalidate all the commit and tag objects.)

In some ways this is similar to the Unix filesystem model of separating location (pathname) from identity (device:inode).

It would also hade the somewhat interesting possibility that one could "remove and recreate" a file and have it exist as a different entity. That probably needs to be a user option.

	-hpa