On Fri, 2005-04-15 at 13:37 +0000, linux@horizon.com 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Apr 15 23:53:32 2005
This archive was generated by hypermail 2.1.8 : 2005-04-15 23:53:32 EST