From: Jens Lehmann <Jens.Lehmann@web•de>
To: henri GEIST <henri.geist@flying-robots•com>
Cc: Junio C Hamano <gitster@pobox•com>,
Heiko Voigt <hvoigt@hvoigt•net>,
Alexei Sholik <alcosholik@gmail•com>,
git@vger•kernel.org, Sverre Rabbelier <srabbelier@gmail•com>
Subject: Re: tracking submodules out of main directory.
Date: Thu, 04 Aug 2011 19:45:52 +0200 [thread overview]
Message-ID: <4E3ADAD0.1060800@web.de> (raw)
In-Reply-To: <1312410562.3261.1030.camel@Naugrim.eriador.com>
Am 04.08.2011 00:29, schrieb henri GEIST:
> Le mercredi 03 août 2011 à 23:30 +0200, Jens Lehmann a écrit :
>> Am 03.08.2011 21:41, schrieb Junio C Hamano:
>>> Jens Lehmann <Jens.Lehmann@web•de> writes:
>> 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.
I don't get this, you can't get rid of the superproject.
> 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.
"git status" inside the submodule won't tell you anything about the
dependencies, but a "git status" in the superproject should. The submodule
shouldn't know where exactly the submodules it depends on lives, that is
the decision of the superproject, not the submodule.
>>>> 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.
But I fail to see how that would improve anything.
>> 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.
Submodules are what you need, but it's no use to implement dependencies by
using gitlinks that point outside of their repositories.
>>>> 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.
No, it doesn't. Apart from the Gimp project telling you what version it
wants, you need to have a place to record the version that the user really
used. And that won't work without a 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.
>>
>> 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.
But being the container that ties it all together is more than enough value.
next prev parent reply other threads:[~2011-08-04 17:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-27 13:07 tracking submodules out of main directory henri GEIST
2011-06-27 16:51 ` Junio C Hamano
2011-06-27 18:14 ` Jens Lehmann
2011-06-27 18:52 ` henri GEIST
2011-06-27 18:56 ` Jens Lehmann
2011-06-27 21:18 ` henri GEIST
2011-06-27 19:05 ` Junio C Hamano
2011-06-27 19:40 ` Jens Lehmann
2011-06-27 21:57 ` henri GEIST
2011-06-28 7:25 ` Jens Lehmann
2011-06-28 11:55 ` henri GEIST
2011-06-27 21:51 ` henri GEIST
2011-06-28 7:20 ` Jens Lehmann
2011-06-28 7:37 ` Jens Lehmann
2011-06-28 11:52 ` henri GEIST
2011-06-28 10:05 ` Alexei Sholik
2011-06-28 17:00 ` Jens Lehmann
2011-07-27 18:49 ` henri GEIST
2011-07-28 8:57 ` henri GEIST
2011-07-28 16:48 ` Jens Lehmann
2011-07-29 9:39 ` henri GEIST
2011-07-30 14:16 ` Jens Lehmann
2011-07-30 21:55 ` henri GEIST
2011-08-01 19:39 ` Jens Lehmann
2011-08-02 12:19 ` henri GEIST
2011-08-02 18:42 ` Jens Lehmann
2011-08-03 6:25 ` Heiko Voigt
2011-08-03 12:26 ` henri GEIST
2011-08-03 17:11 ` Junio C Hamano
2011-08-03 19:07 ` Jens Lehmann
2011-08-03 19:41 ` Junio C Hamano
2011-08-03 21:30 ` Jens Lehmann
2011-08-03 22:29 ` henri GEIST
2011-08-04 17:45 ` Jens Lehmann [this message]
2011-08-05 0:29 ` henri GEIST
2011-08-04 20:05 ` Heiko Voigt
2011-08-05 2:19 ` henri GEIST
2011-08-03 21:45 ` Heiko Voigt
2011-08-03 22:41 ` henri GEIST
2011-08-03 21:49 ` henri GEIST
2011-08-03 21:04 ` henri GEIST
2011-08-01 22:12 ` Heiko Voigt
2011-08-02 12:58 ` henri GEIST
[not found] ` <CAJsNXT=93FHjbi42JKA3Pg7PGXs0kEONJ5AC5SSPpa5RSVqB=A@mail.gmail.com>
2011-08-03 9:07 ` henri GEIST
2011-06-27 18:40 ` henri GEIST
2011-06-27 19:02 ` Jens Lehmann
2011-06-27 21:45 ` henri GEIST
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E3ADAD0.1060800@web.de \
--to=jens.lehmann@web$(echo .)de \
--cc=alcosholik@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=henri.geist@flying-robots$(echo .)com \
--cc=hvoigt@hvoigt$(echo .)net \
--cc=srabbelier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox