On Thursday 24 May 2007, Linus Torvalds wrote: > > On Thu, 24 May 2007, Junio C Hamano wrote: > > > > Why does this have to be out-of-tree and unversioned to begin > > with? > > I _really_ think that the right approach is to > > - have the submodules information under version control (and I'd > personally call it the ".gitmodules" file, but whatever) > > This gives you the defaults, and the ability to change them. Sorry to repeat the obvious. 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)? IMHO we really need 2 kinds of submodule config: (1) One bound to the superproject history (2) One bound _not_ to the superproject history. However, (2) could be put into its own, seperate history/branch, similar to the "todo" branch in the git repository. The tip of the submodule config history, (2) above, would e.g. be available as "ref/submodulesconfig" (and could be checked out by "git-clone" into a separate place like .git/submodulesconfig of the superproject for easy editing). Any "git-fetch" of the superproject would also fetch any changed defaults in the submodulesconfig history. This even allows to override any URL defaults for downstream clones of a superproject repository, by commiting such changes as new revision in the refs/submodulesconfig history. Perhaps I am missing something obvious, but a history for project configuration, completely separate from the project history itself, seems useful in general to me. 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
