Re: organizing multiple repositories with dependencies

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 17.04.2012 22:51, schrieb dag@cray.com:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> 
>> If you work on a subproject (in its own repo) then a subsequent pull
>> in the umbrella project should bring this new code into the umbrella
>> project (assuming that would make sense given the branches involved).
> 
> I don't necessarily think this is always what should happen.

I agree, the reason that we have three different implementations of
subproject support is that there is no model that fits all work flows.

>  I can't
> comment on git-submodule since I haven't used it in its more recent
> incarnation, but one thing I like about git-subtree is that it's
> explicit.  I have to do a "git subtree pull" on the umbrella project to
> pull in the new changes from a subproject.  That gives me some degree of
> control over when to update sources.  I suspect one can do the same by
> using "git pull" in submodule directories.

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

> Perhaps a good way to go would be to provide the basic operations (I
> think we have most of that) and some hooks in contrib/ or elsewere to
> implement various models.  Just like git imposes no particular workflow
> model I don't think git should impose one particular aggregation model.
> What we do need is better documentation of what the various models and
> tools are.  For example, I would find a subtree/submodule comparison
> highly valuable.  It would help people decide which model is best for
> them.

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?