Re: tracking submodules out of main directory.

From: henri GEIST <henri.geist@flying-robots.com>
Date: Aug 3, 2011, 22:29 UTC
Message-ID: <1312410562.3261.1030.camel@Naugrim.eriador.com>
In-Reply-To: <4E39BDFF.3050804@web.de>

Le mercredi 03 août 2011 à 23:30 +0200, Jens Lehmann a écrit :

Show 35 quoted lines

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

Exact, I am really happy to read this. And better do not bother to have the suproject. cd to gimp directory, type git status it can tell you every thing and when your satisfied you just have to type make. At this point the superproject have not any use.

Show 20 quoted lines

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

Yes but for me, from when I started this this topic, it was all about having a loose collection of project with dependency references between them. And get rid of the superproject. It is my first and only goal.

Show 5 quoted lines

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

You just convince me that submodules are more than I need and to make a lighter independent version of submodules which will never been followed by git commands.

Show 6 quoted lines

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

Yes

Show 10 quoted lines

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

Only if you have a superproject. If not do the same thing from the gimp repository, now it contain all necessary infos to do the job.

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

yes but the superproject contain no code in your design. Then it will never need anything by itself. It is only a container which you will inform with data already known by the submodules I do not see any value to it.

	Henri