On Sat, 2 Dec 2006, Josef Weidendorfer wrote: > > > > The current commit within the supermodule would be _totally_ invisible to > > the submodule. > > Of course. > > Yet, you need some name to store meta information of submodules > into some config file of the supermodule, like whether you want to have > it checked out (see below). Yes, you do need to have a list of submodules somewhere, and you'd need to maintain that separately. One of the results of having the submodules be independent from the supermodule is that it's not all "automatically integrated", and thus the supermodule does end up having to have things like that maintained separately. And yes, if you screw that up, you wouldn't be able to fetch submodules properly etc, even if you see the supermodule, and yes, this sounds more like the CVS "Entries" kind of file that is more "tacked on" than really deeply integrated. But I think the separation is _more_ than worth the fact that you can see things being separate. In fact, I'm very much arguing for keeping things as separate as possible, while just integrating to the smallest possible degree (just _barely_ enough that you can do things like "git clone" and it will fetch multiple repositories and put them all in the right places, and "git diff" and friends will do reasonably sane things). Keep it simple, stupid. > > - "git clone" by default will fetch and check out all submodules (and > > obviously they have to be described some way outside of the object > > database, just so that you don't have to parse the _whole_ history of > > the _whole_ supermodule just to find all possible submodules. So the > > supermodule _will_ need some "list of submodules and where to get them" > > in a config file or other). > > Exactly. And in this list, you have to specify names. Yes. > The thing I wanted to discuss is whether such names would need to be globally > unique in the project containing submodles, or not. My preference would be for it to be "local", just because (as I mentioned), with mirroring etc, it might well be that you want to fetch things from the _closest_ repository. That's really not a global decision, it's a local one. > If yes, it IMHO makes a lot of sense to introduce "submodule objects" which contain > these submodule names, and which are used as pointers to submodule commits in > supermodule trees. You could do it that way, and then it would be global. It would work, and in many ways it would probably be "simpler" on a supermodule level. The advantage of a global namespace is that you can much more easily update it - "git fetch" will just fetch the new file(s) that describe the subprojects very naturally if they are all global. Putting them in a local .git/config file has it's advantages (see above), but it also makes it very hard to version them, and to update the list - it would have to become manual. There are possibly combinations of the two approaches: have a "global namespace" that describes the canonical place to get the subprojects, but have some way to add local "translation" of the canonical names into locally preferred versions (eg you could just have a way to say "this is the local mirror for that global canonical place") Maybe that would work? Linus - 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