Am 27.06.2011 23:57, schrieb henri GEIST: > Le lundi 27 juin 2011 à 21:40 +0200, Jens Lehmann a écrit : >> 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. >> > > That is right. > But could also be done with the .gitmodules in project1 containing > > [module "lib1"] > path = ../lib1 > url = ... > > and making implicite if the module is describe in .gitmodules that > mean ./ depend on it. But that would be much more complicated than just recording that in the superproject's .gitmodules. In a Git repo everything lives in a directory tree, if you want to reference something outside of that tree things will get very complicated ... and I'm not sure the benefit is worth the hassle. -- 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