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

Re: On recording renames

From
Junio C Hamano <junkio@cox.net>
Date
Mar 4, 2006, 13:19 UTC
Message-ID
<7v8xrqqrdd.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<7v64muvin9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Show 6 quoted lines
> A bit more on merges and renames...
> The whole thread is worth reading, but the punch line is:
>
>         The transition happened over time with multiple commits.
>         You cannot record "this is the rename" by attributing that
>         information to one particular commit.

After re-reading that thread, and especially the analysis of the history of that part of the kernel source I did back then, I am again convinced that Linus was right when he said "file renames do not matter". That real-life example shows how inadequate file boundaries are when dealing with content changes.

An ideal merge strategy would handle the case where pieces of code gradually moves around across file boundaries. I do not think this is something you can sensibly do by recording file rename history. It would not help the situation a bit even if you gave each file (or content or object or whatever you want to call it) a persistent ID.

One way (now, it is my turn to handwave) to do such a merge might be to take the whole tree as if it were a flat single file (think of it as a concatenation of all files in the tree) with each line tagged with the pathname. You and your friend would start from something like this. A single file that describe topics of interest to both of you:

                    notes.txt:Kernel Topics
                    notes.txt: - filesystem
                    notes.txt: - scheduler
                    notes.txt: - devices
                    notes.txt:Cool Git Topics
                    notes.txt: - git-cvsserver
                    notes.txt: - Cogito

And your friend splits this into two files and starts editing, while you edit the original file:

        your friend                     you
        linux.txt:Kernel Topics         notes.txt:Kernel Topics
        linux.txt: - filesystem         notes.txt: - filesystem
        linux.txt: - scheduler          notes.txt: - scheduler
        linux.txt: - devices            notes.txt: - devices
        linux.txt: - stable driver API  notes.txt: - mm
        git.txt:Cool Git Topics         notes.txt:Cool Git Topics
        git.txt: - git-cvsserver        notes.txt: - git-cvsserver
        git.txt: - Cogito               notes.txt: - gitview
                                        notes.txt: - Cogito
                                        notes.txt: - StGIT
                                        notes.txt: - diff --cc

Now you would want to compare notes and merge them. When comparing these two "trees", the clever merge algorithm would treat this two-column thingy and merge both labels (i.e. pathnames) and contents:

                    linux.txt:Kernel Topics
                    linux.txt: - filesystem
                    linux.txt: - scheduler
                    linux.txt: - devices
                    linux.txt: - mm
                    linux.txt: - stable driver API
                    git.txt:Cool Git Topics
                    git.txt: - git-cvsserver
                    git.txt: - gitview
                    git.txt: - Cogito
                    git.txt: - StGIT
                    git.txt: - diff --cc

It could even guess that the line you touched are related to the hunk your friend moved to another file (iow, your friend gave a new label to the region you touched), and label your new line with the same pathname as surrounding lines.

I suspect this is weave merge taken to its extreme, but I am handwaving so please do not ask me how I would propose to implement it ;-). The point really is that file is a poor unit of operation when dealing with changes.

Previous: Junio C HamanoNext: Linus Torvalds
Message 4 of 5 in “On recording renames”
  1. Junio C HamanoMar 4, 2006
  2. Paul JakmaMar 4, 2006
  3. Junio C HamanoMar 4, 2006
  4. Junio C HamanoMar 4, 2006
  5. Linus TorvaldsMar 4, 2006

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.