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

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: May 25, 2007, 16:23 UTC
Message-ID: <200705251823.37062.Josef.Weidendorfer@gmx.de>
In-Reply-To: <alpine.LFD.0.98.0705250830220.26602@woody.linux-foundation.org>

On Friday 25 May 2007, Linus Torvalds wrote:

Show 8 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.
> 
> You missed the obvious thing here: if a submodule 
> appears/disappears/moves, then the module info *has* to be versioned.

I never refused the need for a versioned .gitmodules file in-tree; I totally agree with you here. Perhaps I forgot to mention this because I took it for granted.

>  - because some people will want to replace repository addresses etc, you 
>    want to have a per-repo (or user, or system) *mapping* of that
>    versioned submodule information,

Yes. So now we have 2 levels of submodule configuration: (1) In-tree, versioned together with the superproject tree (2) Local overrides via .git/config.

AFAICS the whole discussion here is about whether we need a further configuration level with different visibility: one which in not versioned together with the superproject history, but which can be cloned, ie. a superproject-wide configuration (*1*). And I can see a need here for submodule URLs.

But as I just said in another mail in this thread, that would be an additional feature which can be added later if we see that - because of whatever strange use cases for submodules - some git users are forced to constantly adapt 50 URL rewritings in their local config.

Josef

*1* For project-wide configuration, independent of the actual project history, a completely separate branch can be used (lets say refs/projectconfig), which contains one blob, the config file: "projectconfig". By making "git-config" to also parse "refs/projectconfig:projectconfig" before the other config files if existing, this gives us a natural way to provide project wide settings.