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

Re: Handling renames.

From
Llinux@horizon.com <linux@horizon.com>
Date
Apr 15, 2005, 12:03 UTC
Message-ID
<20050415133759.7560.qmail@science.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?

Next: David Woodhouse
Message 1 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.