Re: tracking submodules out of main directory.

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 03.08.2011 21:41, schrieb Junio C Hamano:
> 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

The "depends" information is not very useful inside the superproject,
because when you already know that there you can simply commit version
1.2.3 of Glib together with Gimp instead of adding that information.
That's what gitlinks are for, no?

But when you fetch a new version of Gimp into your submodule, it would be
really nice if the superproject could be notified that the Gimp developers
updated to 1.2.4 of Glib and inform you that an update of Glib might be
appropriate. That could avoid having you to dig through compiler errors to
find out that the new foobar() function from Glib 1.2.4 is needed (and if
you need to pull in a bugfix in Glib, you might notice that *a lot* later
when you forget to do that).

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

Sure, thanks for deciphering that.

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

Let me make this clear: this is not about changing how submodules are
committed in a superproject. It is not about having a loose collection of
projects, they stay tied together in a defined state by the superproject.

Henri wanted it a bit upside down: any submodule could request a certain
version of another submodule somewhere else in the repo. And he wanted to
use gitlinks from one submodule to another for that, which I - hopefully -
convinced him was no good idea.

But I understand his need to have some kind of "version hint" from one
submodule to another. Just that he wants to take the hint very serious,
while I see it as means to communicate from the submodule maintainer to
the superproject developers that another submodule might have to be
updated too when they do that to his.

>> b) And if you don't know where to get it, use this url
> 
> Again that is the job of .gitmodules in the superproject.

Yes. But this idea is about how the url could get into the .gitmodules of
the superproject in the first place. That can make it easier for the
superproject's developer to import a submodule into his repo and much more
important: it makes it possible to pull in submodule dependencies
automatically e.g. when running "git submodule add --resolve-dependencies
Gimp".

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

Right. That's what I tried to explain to Henri, the superproject ties it all
together. But I also like his idea to add a way to communicate information
from the submodule to the superproject, and give the superproject a choice
if it wants to use it.