Re: Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk

Hi,

On Tue, 5 Jan 2010, Heiko Voigt wrote:

On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote:

quoted

On Tue, 5 Jan 2010, Jens Lehmann wrote:

quoted

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