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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 5, 2010, 15:30 UTC
Message-ID: <alpine.DEB.1.00.1001051627250.3361@intel-tinevez-2-302>
In-Reply-To: <20100105142727.GA83546@book.hvoigt.net>

Hi,

On Tue, 5 Jan 2010, Heiko Voigt wrote:

Show 12 quoted lines

> 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.

Show 13 quoted lines

> 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