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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
