In message <CAE1pOi1KnvRk4yxK8OQHi9h_ueNnh5Ar3tbKFBKTA69=Aje0TQ@xxxxxxxxxxxxxx>, Hilco Wijbenga writes:
On 16 April 2012 13:08, <dag@xxxxxxxx> wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html