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

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: May 25, 2007, 14:51 UTC
Message-ID: <200705251651.35234.Josef.Weidendorfer@gmx.de>
In-Reply-To: <Pine.LNX.4.64.0705251514220.4648@racer.site>

On Friday 25 May 2007, Johannes Schindelin wrote:

Show 10 quoted lines

> On Fri, 25 May 2007, Josef Weidendorfer wrote:
> > * 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.

The question here is in how many superprojects the exception will become the rule, which would make manual overriding quite cumbersome.

However, the exact policy for finding a fitting URL for a submodule is not a fundamental design decision, and can be incrementally improved, depending on use cases.

I agree with Junio that a simply, basic and robust submodule implementation currently is important as first goal.

Show 5 quoted lines

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

I totally agree.

Josef