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