Am 27.06.2011 23:51, schrieb henri GEIST: > Le lundi 27 juin 2011 à 12:05 -0700, Junio C Hamano a écrit : >> 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"? >> >> > > This could be a way if .gitmodules can contain something like > > [module "project one"] > path = project1 > url = ... > depends = lib1 "123456" > [module "project two"] > path = project2 > url = ... > depends = lib1 "abcdef" > [module "lib1"] > path = lib1 > url = ... But there is no need for that as "123456" and "abcdef" are already present as the sha1 values for the gitlinks "lib1" and "lib2". -- 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