git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Handling renames.

From
David Woodhouse <dwmw2@infradead.org>
Date
Apr 15, 2005, 13:53 UTC
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:
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
Previous: linux@horizon.com
Message 2 of 2 in “Re: Handling renames.”
  1. linux@horizon.comApr 15, 2005
  2. David WoodhouseApr 15, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.