> One option for optimising this, if we really need to, might be to track > the file back to its _first_ ancestor and use that as an identification. > The SCM could store that identifier in the blob itself, or we could > consider it an 'inode number' and store it in git's tree objects.
This suggestion (and this whole discussion about renames) has issues with file copies, which form a branch in the revision history. If I copy foo.c to foo2.c (or fs/ext2/ to fs/ext3/), then the oldest ancestor isn't a "unique inode number". I've written a lot of programs by debugging hello.c. Thinking about this can give you all sorts of exciting merge possibilities. If branch1 renames a.c to b.c, and branch2 patches a.c, it seems obvious that the patch should be merged into b.c. But what if branch1 copies a.c to b.c? - 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
