Ramkumar Ramachandra <artag...@gmail.com> writes: > Meanwhile, you're evading the issue of assuming that all trees are > read into /, and are really representing the same project's history, > while this is not the case.
This is fundamenally how Git works. Git works with commit objects, each commit object points to a tree object that represent "/" at this commit. When you do a subtree merge, you include the tree that was in "/" in a subtree of the master project. Files used to exist as /file, and now exist as /subtree/file. There is nothing recording that the new /subtree/file comes from /file in its second parent. Call this a renaming or not, but "git log subtree/file" won't show you changes touching "/file" by default, and this is the case for the history of the subproject you are merging. A subtree merge is really a rename of the subproject's file plus a merge, done in the same commit. Try doing something like mkdir -p subproject git mv * subproject/ git commit in your subproject before doing a merge, you'll get the same result, except there will be one more commit. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
