On 6/12/07, Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> wrote:
Lars Hjemli wrote: > > (readded the gitlist) > > On 6/12/07, Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> wrote: > > Lars Hjemli wrote: > > > Multiple checkout paths for a single submodule will bring havoc on > > > this plan, so I need to ask: what is the use-case for multiple > > > checkout paths? > > > > A use-case is the admin directory in the KDE repository. It has: > > > > KDE (superproject) > > +- kdelibs (subproject) > > | +- admin (subproject) > > | +- subdir1 > > | +- ... > > +- kdebase (subproject) > > | +- admin (subproject) > > | +- subdir2 > > | +- ... > > +- kdenetwork (subproject) > > | +- admin (subproject) > > | +- subdir3 > > | +- ... > > ... > > But in this case, 'admin' isn't a submodule/subproject contained by > KDE, right? It's contained in three different submodules/subprojects: > kdelibs, kdebase and kdenetwork. Notice how kdelibs, kdebase and kdenetwork are both submodule and supermodule: They host the submodule admin and are hosted by KDE.
Exactly my point ;-)
(If I missed the point, then it's because I didn't follow the discussion; I jumped in because I noticed the symlink proposal by chance.)
In this case, I would assume that e.g. kdelibs contain a submodule entry for path admin in its index, accompanied by a .gitmodules file saying that the path admin is mapped to this or that submodule. I would not expect the KDE 'supersuperproject' to know about admin at all, neither in its index nor .gitmodules. -- larsh - 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
