On Fri, 2005-04-15 at 13:37 +0000, [EMAIL PROTECTED] wrote: > > 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".
That's why I prefer the option of simply annotating the moves. They don't need to be just renames -- it can cover the cases where files are split up or merged into one, to indicate where the history of the given _data_ is coming from. -- dwmw2 - 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
