On Friday 25 May 2007, Johannes Schindelin wrote: > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
