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
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

Reply via email to