Re: tracking submodules out of main directory.

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2011, 19:41 UTC
Message-ID: <7vaabqb7vf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E399C62.30604@web.de>

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

Show 6 quoted lines

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