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 = ...
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