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

Hi,

On Thu, 24 May 2007, Sven Verdoolaege wrote:

On Thu, May 24, 2007 at 02:17:27PM +0100, Johannes Schindelin wrote:

quoted

On Thu, 24 May 2007, Sven Verdoolaege wrote:

quoted

I suppose we could just set it to 0.
I also don't think the URL should be associated to a ref.

It does not need to be.

But then, it is sort of a "subref": You could just clone the submodule in 
its own right, correct?

Exactly, but the information we want is not associated to any
particular revision of the submodule.  It just points to the repo.
It's also not associated with any revision of the supermodule.
That information should go in a tracked .gitmodules file.

It is not that expensive to just give the SHA-1 with the URL, and to 
introduce a new namespace, say

3f... submodule/path^{URL:blablub}

to say that the submodule which is connected in "HEAD:path" is available 
with the URL "blablub" and just so happens to be at commit "3f..." at the 
moment. Heck, you can even use this instead of expensive fetches to verify 
up-to-date, and even more, you can make sure that you are as up-to-date as 
the remote supermodule.

But then, I do not care about that deeply. Like I said, I haven't followed 
the discussions, but I really do not understand why an information as 
essential to a superproject is not contained in something like 
HEAD:.gitmodules. Git does not have to take it from there, it can still 
continue to take it from a local config in .git/, but .gitmodules can live 
in the tree happily, for the pleasure of the tools (if only to initialise 
the first version of the local config after clone).

Without some very intrusive surgery into the transport code of Git, in 22 
patches, which I am not at all comfortable with.

Ciao,
Dscho