threads / discuss / 34

Re: Handling renames.

Subject: Re: Handling renames.

## tl;dr

2 messages between Apr 15, 2005 and Apr 15, 2005.

replies: 1people: 2as markdown or json

linux@horizon.com· Apr 15, 2005, 12:03 UTC · lore

> 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?

David Woodhouse· Apr 15, 2005, 13:53 UTC · re: linux@horizon.com · lore

On Fri, 2005-04-15 at 13:37 +0000, linux@horizon.com wrote:

Show 9 quoted lines

> > 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