On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote: > On Tue, 5 Jan 2010, Jens Lehmann wrote: > > Yes. This synchronization could be either obsoleted by only using > > .gitmodules or automated. > > I start to wonder whether the insistence that .gitmodules' settings must > be overrideable makes any sense in practice. I just read this and felt the need to comment. Yes, it definitely makes sense in practise to have it overrideable otherwise we loose the distributed nature of git for submodules. Imagine you fork a project and you want to work with others on a change that involves chaning a subproject. If you can not override .gitmodules you can only work on the central repository. I am actually working like this in practise. I have a private clone of all the subprojects msysgit has and commit/push locally first. Once I sense the change is going to be useful for a wider audience I send it upstream. This would be more uncomfortable if it is not overideable. But I know what you mean by the general confusion about manual updates. So how about an approach like this: * clone will initialise all submodules in .git/config from .gitmodules * if a change in .gitmodules happens git scans .git/config for that entry and in case nothing is there it syncronises the new one and notifies the user. * if a change in .gitmodules happens and the entry before was the same in .git/config we also automatically update that entry there. * In every other case we just leave .git/config alone. Did I miss anything? I think you should get the idea and that it could get rid of the confusion caused by manual .gitmodule updates. cheers Heiko P.S.: Additionally (for my use case) we could add a "hint mechanism" which allows git to "guess" a new submodules address. For example in case I have all my local clones on "git@xxxxxxxxxxxxx:<modulename>.git". Now when a new submodule gets seen in .gitmodules it will infer the address from the hint configuration and not take the original one from upstream. -- 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