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

[Sven Verdoolaege <skimo@kotnet.org>]

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