Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> It's explicit too when using submodules, you can update each submodule
> to the commit you want, review and test that and then decide if you want
> to commit that (or e.g. it's parent) in the superproject or just rewind
> the submodule because the new changes don't work for you.
Yes, that is very useful.
> For a lot of use cases an automatic pull of changes you haven't even
> seen yet and then automatically promote them to the superproject
> (which is how I understand "git subtree pull", but I might be wrong)
> is undesirable, for others it might very well work.
Since subtrees are really just directories in a single-history
repository, a subtree pull does "prommote" the changes to the
superproject because there is no superproject/subproject. That's one of
the reasons subtree can be used to create subprojects out of existing
repositories.
Subtrees and submodules really are very different models. I see
advantages and dsadvantages to both depending on one's work flow.
> I agree and am willing to provide information about submodule use cases,
> advantages and problems, but I'm not a user of subtree so I can't really
> comment on it. Now that subtree is in git core, what about putting such
> a comparison under Documentation/subproject-support.txt?
That would be great. Do you want to start work on that? I can
contribute some text about git-subtree.
-Dave
--
To unsubscribe from this list: 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