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.