Re: [PATCH/RFC v2] git-submodule: multi-level module definition

From: Ping Yin <pkufranky@gmail.com>
Date: Mar 6, 2008, 05:18 UTC
Message-ID: <46dff0320803052118j2296a2d4p397fa889f8cea45b@mail.gmail.com>
In-Reply-To: <alpine.LSU.1.00.0803060330210.15786@racer.site>

On Thu, Mar 6, 2008 at 10:32 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 20 quoted lines

> Hi,
>
>
>  > >  The place the owner of the repository (not the project) expresses which
>  > >  modules are of interest, what transports she wants to use to access it,
>  > >  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to
>  > >  be used when the user populates that information.
>  > >
>  > Not always the case.
>
>  If it is _not_ always the case, .gitmodules is definitely the wrong place,
>  and $GIT_DIR/config is.
>
>  Just like we need "init && update", and not have "init" update implicitly,
>  like some people wish (who forget that other people might have other
>  wishes), we need to allow for different options here.
>
>  And as .gitmodules is _meant_ to be tracked, it is not the place to
>  express individual wishes differing from the colleagues' wishes.
>

As an analogy, .gitignore is for colleagues' wishes and .git/info/exluces is for individual wishes. The same, .gitmodules is for colleagues' wishes and .git/config is for individual wishes.

There are always common cases and special cases, so we need a machinsm to support both of them.

>  Ciao,
>  Dscho
>
>

-- 
Ping Yin