On Friday 25 May 2007, Linus Torvalds wrote: > On Fri, 25 May 2007, Josef Weidendorfer wrote: > > > > * 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. > > You missed the obvious thing here: if a submodule > appears/disappears/moves, then the module info *has* to be versioned. I never refused the need for a versioned .gitmodules file in-tree; I totally agree with you here. Perhaps I forgot to mention this because I took it for granted. > - because some people will want to replace repository addresses etc, you > want to have a per-repo (or user, or system) *mapping* of that > versioned submodule information, Yes. So now we have 2 levels of submodule configuration: (1) In-tree, versioned together with the superproject tree (2) Local overrides via .git/config. AFAICS the whole discussion here is about whether we need a further configuration level with different visibility: one which in not versioned together with the superproject history, but which can be cloned, ie. a superproject-wide configuration (*1*). And I can see a need here for submodule URLs. But as I just said in another mail in this thread, that would be an additional feature which can be added later if we see that - because of whatever strange use cases for submodules - some git users are forced to constantly adapt 50 URL rewritings in their local config. Josef *1* For project-wide configuration, independent of the actual project history, a completely separate branch can be used (lets say refs/projectconfig), which contains one blob, the config file: "projectconfig". By making "git-config" to also parse "refs/projectconfig:projectconfig" before the other config files if existing, this gives us a natural way to provide project wide settings. - 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
