Re: organizing multiple repositories with dependencies

From: dag@cray.com <dag@cray.com>
Date: Apr 17, 2012, 20:51 UTC
Message-ID: <nng1unmnksx.fsf@transit.us.cray.com>
In-Reply-To: <CAE1pOi29dKd2LHW7MJ+TTN4HzFkOPFEyf7Sf2emSsBYm93uYUA@mail.gmail.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