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

From: Sven Verdoolaege <skimo@kotnet.org>
Date: May 25, 2007, 10:00 UTC
Message-ID: <20070525100030.GB942MdfPADPa@greensroom.kotnet.org>
In-Reply-To: <Pine.LNX.4.64.0705241908040.4648@racer.site>

I'm obviously not going to stop anyone from putting URLs in .gitmodules and I can see that it would be useful in practice, but I still think that it doesn't matter where the submodule was located at any given point in history (from the point of view of the superproject). It only matters where the submodule is located now.

You may be bisecting a problem and you may need to clone a submodule for a point in history when the submodule was placed somewhere else. (You may not have had a need to checkout the submodule before, or it may simply not be used in the current version of the supermodule.) So, I think it would still be useful to have an optional additional out-of-tree mechanism of getting usable URLs if the URLs in .gitmodules or your local config don't work.

On Thu, May 24, 2007 at 07:11:31PM +0100, Johannes Schindelin wrote:

Show 5 quoted lines

> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > If you allow an override, then I don't see how having the initial
> > information in the tree is any better.
> 
> Isn't that obvious? _Most_ people will _not_ override the information.

You may be asked to.

	"Please clone from a mirror close to you and after cloning,
	 please change the URLs of these 54 submodules to a mirror
	 close to you."

> Plus, it is an easy solution to your problem, without having to touch a 
> lot of real core parts of Git. Simple is beautiful. And less buggy.

I'll take your word for it.

> > He needs to modify .gitmodules, but when the changes go upstream,
> > this .gitmodules changes get merged as well.
> 
> If you change the superproject, that is.

That's what I meant.  Plus, other users may want to pull from such forks too.

skimo