Am 27.06.2011 18:51, schrieb Junio C Hamano: > One possible working tree organization may look like this: > > -+- lib1 > +- project1/Makefile -- refers to ../lib1 > +- project2/Makefile -- refers to ../lib1 This is what we do at work and it works really well for us. The possible downside (that you can't tie project1 and project2 to a specific version of lib1 in their own repo) is not a real problem in our experience, as the superproject ties the correct combination together. > An interesting point your situation raises is that there is no direct way > to express module dependencies in .gitmodules file right now, I think. > Ideally you would want "submodule init project1" to infer automatically > that project1 needs lib1 and run "submodule init lib1" for you. My gut > feeling is that it belongs to .gitmodules of the superproject That is where this is handled now, but having a submodule refer to a submodule outside of it as a dependency is an interesting thought. But as that only matters at the moment you add project1 (and it won't compile because ../lib1 is missing, which can easily handled by: "oh, then I have to add lib1 as a submodule to the superproject too"), I'm not sure that would be a huge improvement over just having a sane convention of where to get lib1 from. -- 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