On Tuesday 12 June 2007, Johannes Sixt wrote: > Josef Weidendorfer wrote: > > However, to not have a lot of copies of the admin submodule > > in > > > > .git/submodule/admin > > .git/submodule/kdelibs/.git/submodule/admin > > .git/submodule/kdebase/.git/submodule/admin > > .git/submodule/kdenetwork/.git/submodule/admin > > > > the just suggested submodule.<name>.repopath to specify a repository > > outside of .git/submodule to be shared by kdelibs,kdebase,... would > > be fine. > > This clearly shows that having the repositories of submodules in > .git/submodule does not buy you enough to avoid duplication. The .git/submodule space for sure is not flexible enough for all possible use cases of submodules (as with KDE repo). However, as default it seems fine to me. IMHO sharing of the admin submodule repository should even be possible if I have a clone of kdelibs and kdebase independent of the big KDE superproject. It would be nice to allow submodule.<name>.repopath configs globally in ~/.gitconfig, and cloning kdelibs should automatically do the right thing, ie. use the already available admin repo for the kdelibs clone. > (I don't see enough reason to place a repo for submodule X in project Y > outside its "natural" checked-out directory in project Y. But then, I > haven't followed the discussion. To easily share the objects, branches and local modifications? Currently a clone of a superproject always does a full copy of any submodule databases because it is independent from any other local git repository; in the KDE case you would get >4 admin copiess if recursive cloning of submodules inside of submodules does that. Josef - 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
