On 17 April 2012 11:37, Seth Robertson <in-gitvger@xxxxxxxx> wrote: > 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. Well, since I seem to have pretty much everyone who is involved with "subprojects" (be it submodules, subtree, or gitslave) in this thread, I wanted to clarify what I meant with "not supported well in Git". To me, subproject support is one of the most important pieces missing in Git. Git submodules, subtree and gitslave all provide a part of what I'm looking for: non-invasive subproject support. I would like to be able to use normal Git commands on the umbrella project that "trickle down" to the subprojects. 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). After rereading my earlier reply I felt that it might be interpreted as being disparaging of submodules/subtree/gitslave. I just wanted to make clear that that was not my intent. I'm hopeful that we can get some sort of combination of submodules, subtree and gitslave to provide subproject support in Git. -- 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