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. Otherwise your module setup will be *wrong*. Think about it. If you move the kernel module somewhere else (say, you make it be in "old-kernel"), and then replace the "kernel" module with a _new_ submodule, if you don't version the .gitmodules file, you're simply _screwed_. You'll be loading the "kernel" module from the wrong place when you move around in history! In contrast, if you version it, everything JUST WORKS. So: - submodule information *has* to be versioned. If it isn't, it's broken. It really _is_ that simple. - 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, so that people can override the actual location. But that doesn't obviate the need for the basic module information having to be versioned. So no, we cannot have the fundamental module info setup anywhere else than in something like .gitmodules. Linus - 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