Re: tracking submodules out of main directory.

> Am 27.06.2011 21:05, schrieb Junio C Hamano:
> > Jens Lehmann <Jens.Lehmann@web.de> 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.
>