Jens Lehmann <Jens.Lehmann@xxxxxx> 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.
--
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