{"thread":{"id":"34","subject":"Re: Handling renames.","startedAt":"2005-04-15T12:03:08Z","lastAt":"2005-04-15T13:53:12Z","messageCount":2,"participants":["linux@horizon.com","David Woodhouse"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209","messageId":"20050415133759.7560.qmail@science.horizon.com","threadId":"34","inReplyTo":null,"subject":"Re: Handling renames.","fromName":"","fromEmail":"linux@horizon.com","sentAt":null,"receivedAt":"2005-04-15T12:03:08Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> One option for optimising this, if we really need to, might be to track\n> the file back to its _first_ ancestor and use that as an identification.\n> The SCM could store that identifier in the blob itself, or we could\n> consider it an 'inode number' and store it in git's tree objects.\n\nThis suggestion (and this whole discussion about renames) has issues\nwith file copies, which form a branch in the revision history.  If I\ncopy foo.c to foo2.c (or fs/ext2/ to fs/ext3/), then the oldest ancestor\nisn't a \"unique inode number\".\n\nI've written a lot of programs by debugging hello.c.\n\nThinking about this can give you all sorts of exciting merge possibilities.\n\nIf branch1 renames a.c to b.c, and branch2 patches a.c, it seems obvious\nthat the patch should be merged into b.c.  But what if branch1 copies a.c\nto b.c?\n"},{"id":"210","messageId":"1113573192.27227.45.camel@hades.cambridge.redhat.com","threadId":"34","inReplyTo":"20050415133759.7560.qmail@science.horizon.com","subject":"Re: Handling renames.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-15T13:53:12Z","receivedAt":"2005-04-15T13:53:12Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2005-04-15 at 13:37 +0000, linux@horizon.com wrote:\n> > One option for optimising this, if we really need to, might be to track\n> > the file back to its _first_ ancestor and use that as an identification.\n> > The SCM could store that identifier in the blob itself, or we could\n> > consider it an 'inode number' and store it in git's tree objects.\n> \n> This suggestion (and this whole discussion about renames) has issues\n> with file copies, which form a branch in the revision history.  If I\n> copy foo.c to foo2.c (or fs/ext2/ to fs/ext3/), then the oldest ancestor\n> isn't a \"unique inode number\".\n\nThat's why I prefer the option of simply annotating the moves. They\ndon't need to be just renames -- it can cover the cases where files are\nsplit up or merged into one, to indicate where the history of the given\n_data_ is coming from.\n\n-- \ndwmw2\n\n"}]}