Re: organizing multiple repositories with dependencies

In message <CAE1pOi1KnvRk4yxK8OQHi9h_ueNnh5Ar3tbKFBKTA69=Aje0TQ@mail.gmail.com>, Hilco Wijbenga writes:

    On 16 April 2012 13:08,  <dag@cray.com> wrote:
    > Jakub Narebski <jnareb@gmail.com> writes:
    >> Put reusable library in its own repository, and use submodules to link
    >> it up to project-a and project-b repositories.

    If you really have only one or two libraries then submodules will work
    just fine but if you have quite a few (we had around 50 when we moved
    away from submodules) you will find it pretty much unworkable. [...]
    Branches are per submodule but you want them for all
    submodules. You might want to look into git-slave if you want to
    go this route.

    In general, I do not think the blanket statement "one repo per
    project" is good advice. If projects depend on each other they should
    be in the same repo. At least with the current support in GIt for
    including separate projects. Please note that I'm not disagreeing with
    the notion "one repo per project" itself. It's just not supported well
    enough to be feasible if you have a fairly large group of projects
    that depend on each other.

As you mentioned, this is exactly the environment that gitslave was designed for. It provides the flexibility to work on the subprojects as if they were standalone independent git repositories (which of course they are) or treat the entire superproject as one giant git repository (with only a few cracks showing through). All gitslave commands are just git commands (s/^git\s/gits /) so training to use it is rather easy.

Unlike with git-submodules there is no strict binding between the parent repo's commits and the sub-project's commits except at tag boundaries. This gives you the flexibility of person A saying that A is master and B is underneath it while person B says that B is master and A is underneath it (or alternatively you can also say that A include B plus whatever B includes). However, I would in general recommend that the common library be factored out and be a child of A and B. gitslave makes it trivial to work with federated git repositories, if you can handle only having binding between repositories at tag boundaries.

					-Seth Robertson