From: Johannes Schindelin Date: Tue, 05 Jan 2010 15:30:49 GMT Subject: Re: Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk Message-ID: In-Reply-To: <20100105142727.GA83546@book.hvoigt.net> 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..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