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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Fri, 25 May 2007, Josef Weidendorfer wrote:

> 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