From: Sven Verdoolaege <skimo@kotnet.org>
Date: Tue, 12 Jun 2007 19:10:48 GMT
Subject: Re: [PATCH 5/5] Add gitmodules(5)
Message-ID: <20070612191048.GX955MdfPADPa@greensroom.kotnet.org>
In-Reply-To: <7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com>

On Tue, Jun 12, 2007 at 12:03:10PM -0700, Junio C Hamano wrote:
> Johannes Sixt <J.Sixt@eudaptics.com> 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