Am 27.06.2011 21:05, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> 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 >> ... >>> 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"), ... > > That is what I called "there is no direct way". Wouldn't it be nicer if > the .gitmodules file in the superproject said something like > > [module "project one"] > path = project1 > url = ... > depends = lib1 > [module "lib1"] > path = lib1 > url = ... > > and then "git submodule init project1" run by the end user implied running > also "git submodule init lib1"? And if lib1 happens to have another dependency, that will be initialized too? That would make life much easier for users who only want certain submodules populated to work on, as they won't have to chase compile errors anymore until they found all necessary submodules ... very nice. -- 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