On Tuesday 22 April 2008, Ping Yin wrote: > On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > It does not help motivating me reviewing the series that the overall tone > > of it is to ignore .git/config more and make .gitmodules take more active > > role, either. I have already said number of times why that is not a good > > idea and why it is against the overall submodule design. > > I summarize junio's points that says $GIT_DIR/config is authoritative. > > [...] > > Any others? 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
