A reason you did not mention is security:
You never want your .git/config to be changed behind your back, which
effectivly is the case when using the versioned .gitmodules information
(similar problem as with a .gitconfig in-tree).
Another one:
From a design point of view, submodule URLs are project meta information
unrelated to source history. So, actually, I think it was wrong to put
submodule URLs (even hints only) into the versioned .gitmodules files (*).
The main reason for .gitmodules is to store submodule information which
has to be in sync with commits, such as a submodule name related to some
path where the submodule happens to be checked out in a given commit, and
also related to some config entry holding the URL to allow for fetch/pull.
The idea is that submodules have an identity in the supermodule (in contrast
to files in git), such that related configuration keeps valid when moving
submodules around. This needs simultanous adjusting the path attribute in
.gitmodules when a submodule is moved.
Josef
(*) IMHO, it would be far better if such project meta/policy information could
be in its own history (e.g. branch "gitconfig" to allow for easy propagation
at clone/fetch time). However, any such configuration should need
explicit interaction by the user to take over project config into the
local git config (e.g. via a "git config merge gitconfig:config" after
inspecting via "git show gitconfig:config").
--
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
