Re: tracking submodules out of main directory.

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> 1) To use me, you need another submodule "foo"
>
>    This is very helpful when you want to add the Gimp submodule and it
>    can tell you you'll need the libpng submodule too in your superproject
>    (but I'd vote to use the submodule name here, not the path as that
>    should be the superproject's decision).

That is something you can add to .gitmodules in the superproject, no?
E.g.

	[submodule "Gimp"]
        	url = http://some/where/
		path = gimp/
        	depends = version 1.2.3 of "Glib"

	[submodule "Glib"]
        	url = http://some/where/else/
		path = libs/glib

> In addition to that, it can (but mustn't) specify any of the following:

I am guessing you meant "does not have to", instead of mustn't, here...

> a) Of this submodule "foo" I need at least that version because I won't
>    compile/work with older versions of that. (this can be tightened to
>    "exactly that version" to give henri the behavior he wants, but that
>    should be policy, not mandatory)

The "loose collection of projects" approach like that has its uses, and it
is called "repo". Why re-invent it? The behaviour Henri wants to specify
the exact version is how git submodules work already, so I do not see
there is anything to be done here.

> b) And if you don't know where to get it, use this url

Again that is the job of .gitmodules in the superproject.

> That is all stuff the submodule knows better than the superproject.

Not necessarily. The version A0 of submodule A may depend on submodule B
and may also know it must have at least version B0 of that submodule, but
the superproject would know other constraints, e.g. the superproject
itself also calls into submodule B and wants a newer version B1 of it.