Re: [PATCH 5/5] Add gitmodules(5)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2007, 19:03 UTC
Message-ID: <7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com>
In-Reply-To: <466E7A17.CEB0F196@eudaptics.com>

Johannes Sixt <J.Sixt@eudaptics.com> writes:

Show 21 quoted lines

> 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?

It makes me wonder if the KDE's layout you quoted is a good practice we would want to recommend for other people to follow. If not, I doubt it is a good idea to model our important concept after that layout to begin with.