From: dag@cray.com
Date: Tue, 24 Apr 2012 17:22:59 GMT
Subject: Re: organizing multiple repositories with dependencies
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