Junio C Hamano <junkio@xxxxxxx> writes:
> 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.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html