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 $gmane/217, perhaps? 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 "gitk-git/gitk". The only difference the above imaginary history has from the reality is Paul's history does not share that root, but everything else is the same. -- 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
