From: David Woodhouse Date: Fri, 15 Apr 2005 13:53:12 GMT Subject: Re: Handling renames. Message-ID: <1113573192.27227.45.camel@hades.cambridge.redhat.com> In-Reply-To: <20050415133759.7560.qmail@science.horizon.com> 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