> >>> > >>> 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. > I am actually working on the git source code to give it a try and see if I can managed to make a patch without breaking anything else. Henri GEIST -- 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