Ramkumar Ramachandra <artag...@gmail.com> writes:
> Am I making any sense?
I dunno. Depends on the definition of "sense".
It sounds like you are repeating the same old "let's record renames
in the commit", and in a system (not Git) where recording renames
may make sense, you may be making sense.
But we will not record renames in the commit. Time to re-read
A subtree merge that slurps everything from a side branch under a
single directory, say gitk/, is not at all different from a normal
merge with many renames.
Imagine an alternate world where we had a small "git.git" project
with 11 files totallying 1244 lines. Then Paul Mackerras forks that
project, remove everything from the top-level directory and adds a
Tck/Tk script "gitk". Linus merges that history as-is, keeping all
our files intact (i.e. ignoring his removal) but taking the addition
of "gitk" from him.
Then after I inherit the project, I rename "gitk" to "gitk-git/git".
Paul does not rename his. We keep developing in parallel and I
occassionally merge from his tree, which has "gitk" at the top,
while mine has it in a directory "gitk-git". The ordinary rename
detection kicks in and integrates his updates to "gitk" into my
The only difference the above imaginary history has from the reality
is Paul's history does not share that root, but everything else is
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html