On Tue, Jun 12, 2007 at 12:03:10PM -0700, Junio C Hamano wrote: > Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes: > > > 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 > > | +- ... > > ... > > If these three instances of 'admin' are truly the same project > created in multiple places in the directory hierarchy, what is > the reason that it is not arranged like this instead? > > KDE > +- admin > +- kdelibs > | +- subdir1 > | +- ... > +- kdebase > | +- subdir2 > | +- ... > +- kdenetwork > | +- subdir3 > | +- ... > ... > > When kdelibs/subdir1 needs to access stuff in admin, instead of > going to ../admin, it could very well go to ../../admin couldn't > it? In Hannes' example, kdelibs and kdebase are subprojects of their own. Surely, you wouldn't want them to depend on something outside of the (sub)project. But even in a similar situation where the different parts do not exist as separate projects, they may advance at a different pace and therefore need different revisions of the same subproject. skimo - 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
