On Friday 25 May 2007, Johannes Schindelin wrote:
quoted text
> > I assume you talk about a versioned .gitmodules file tied to the
> > superproject history, and any fetch/pull would look into this
> > file from the current working directory to lookup the default URL.
> > 
> > Wouldn't this have the problem that when you check out an old
> > revision of the superproject you get out-of-date URLs, so that
> > a fetch does not work (without local overrides)?
> 
> If you check out an old revision, wouldn't you have that _already_, so it 
> does not matter what URL is given in .gitmodules?

Not necessary.
* 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.

Above points make it necessary for the submodule feature to implement
lazy clones. You want be able to clone a submodule without error independent
of the superproject HEAD. IMHO it would be really bad porcelain design
to break out with an error each time and expect the USER to manually
override submodule URLs.

Another difference between in-tree .gitmodules and out-of-tree submodule
config is that for in-tree you any want to see configuration for submodules
which happen to be part of the superproject at this point in history.
For out-of-tree config, there has to be information for every submodule which
was referenced in the whole history of the superproject.

Josef
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html