Re: organizing multiple repositories with dependencies

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

If you want the behavior you describe, a post-receive hook on the
component repositories is easy to implement.  I just did that a couple
of weeks ago for a subtree-aggregated repository.  When a component
receives something it immediately does a "git subtree pull" on a
workarea on the server and then does a push from that workarea to the
subtree-aggregated repository.

Of course, this is entirely driven by git-subtree's model of actually
incorporating subproject history into one big umbrella repository.
There is no separation between the subprojects and umbrella projects.
It's one giant history.  Therefore, push/pull to/from subprojects are
explicit operations.  That's probably not the best model for every
situation but I find it very nice.

> After rereading my earlier reply I felt that it might be interpreted
> as being disparaging of submodules/subtree/gitslave.

I didn't interpret it that way at all.  I agree with you that
subproject/superproject support could be much better.  But I don't agree
that we'll be able to design one model that works for everyone.  svn
externals are just one model to aggregate projects but it is not the
only one.  It just happens that no one working on Subversion bothered to
implement anything else.

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.

                                -Dave