# Re: Handling renames.

2 messages from 2005-04-15 to 2005-04-15. Participants: linux@horizon.com, David Woodhouse.
Thread: https://gitlist.dev/t/34

## linux@horizon.com, 2005-04-15 12:03

Subject: Re: Handling renames.
Message-ID: <20050415133759.7560.qmail@science.horizon.com>
URL: https://gitlist.dev/e/20050415133759.7560.qmail%40science.horizon.com

```
> 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, 2005-04-15 13:53

Subject: Re: Handling renames.
Message-ID: <1113573192.27227.45.camel@hades.cambridge.redhat.com>
URL: https://gitlist.dev/e/1113573192.27227.45.camel%40hades.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


```