Re: organizing multiple repositories with dependencies

From: dag@cray.com <dag@cray.com>
Date: Apr 24, 2012, 17:22 UTC
Message-ID: <nngbomh3uz0.fsf@transit.us.cray.com>
In-Reply-To: <4F8EB157.5060707@web.de>

Jens Lehmann <Jens.Lehmann@web.de> 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