Re: tracking submodules out of main directory.

From: Jens Lehmann <jens.lehmann@web.de>
Date: Aug 3, 2011, 21:30 UTC
Message-ID: <4E39BDFF.3050804@web.de>
In-Reply-To: <7vaabqb7vf.fsf@alter.siamese.dyndns.org>

Am 03.08.2011 21:41, schrieb Junio C Hamano:

Show 20 quoted lines

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

Show 9 quoted lines

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

Show 6 quoted lines

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