Re: [RFC] Fourth round of support for cloning submodules

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 25, 2007, 14:16 UTC
Message-ID: <Pine.LNX.4.64.0705251514220.4648@racer.site>
In-Reply-To: <200705251559.53846.Josef.Weidendorfer@gmx.de>

Hi,

On Fri, 25 May 2007, Josef Weidendorfer wrote:

Show 20 quoted lines

> On Friday 25 May 2007, Johannes Schindelin wrote:
> > > I assume you talk about a versioned .gitmodules file tied to the
> > > superproject history, and any fetch/pull would look into this
> > > file from the current working directory to lookup the default URL.
> > > 
> > > Wouldn't this have the problem that when you check out an old
> > > revision of the superproject you get out-of-date URLs, so that
> > > a fetch does not work (without local overrides)?
> > 
> > If you check out an old revision, wouldn't you have that _already_, so it 
> > does not matter what URL is given in .gitmodules?
> 
> Not necessary.
> * Submodules can appear/disappear any time in the superproject.
> Therefore, going back in time can make it necessary to have to clone
> a submodule you did not have before.
> * Not every submodule is interesting for every developer; therefore,
> an important design-decision for submodules is to allow at git-clone time
> to not clone some submodules at all. However, you can change your mind and
> want to follow a given submodule later.

Okay, so there are exceptions to the rule, just as everywhere.

We already talked about being able to override .gitmodules from .git/config. I think that should really, really be sufficient, as you cannot hope to have a one-size-fits-them-all solution for the exceptions you described. You'll have to cope with them manually anyway.

We should not design for the exception. Therefore I think the .gitmodules, overrideable by .git/config is sufficient.

And the point about my config being private still stands. You have no business looking into my config.

Ciao, Dscho