Hi, On Tue, 5 Jan 2010, Heiko Voigt wrote: > 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. AFAICT you can use url.<base>.insteadOf for that. Or maybe even better use a different remote for that, as you are likely wanting to stay up-to-date with the upstream projects even if you work on the stuff locally. > 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. I'm sorry, but this is the kind of stuff I am seeing in Git: a lot of really complicated design with a lot of corner cases, put on top of a really simple and elegant design. So I'd like to see a solution that is obviously superior by being plain simple. Ciao, Dscho -- 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