Re: Moved files and merges

["H. Peter Anvin" <hpa@zytor.com>]

Junio C Hamano wrote:
> 
>>  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