From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Tue, 19 May 2009 08:17:29 GMT
Subject: Re: What's cooking in git.git (May 2009, #02; Sun, 17)
Message-ID: <alpine.DEB.1.00.0905191015560.26154@pacific.mpi-cbg.de>
In-Reply-To: <200905190923.33874.johan@herland.net>

Hi,

On Tue, 19 May 2009, Johan Herland wrote:

> On Tuesday 19 May 2009, Junio C Hamano wrote:
> > Johan Herland <johan@herland.net> writes:
> > > After some thinking, I don't like my original name 
> > > submodule.<name>.resolve, since ".resolve" sounds more like a merge 
> > > strategy or conflict resolution method, than a "how to deal with 
> > > submodule update" choice. I propose submodule.<name>.update instead.
> >
> > Sounds like a plan, even though I do not necessarily agree with the 
> > idea of automatically rebinding what is at the submodule path every 
> > time you update the toplevel project tree.
> 
> I agree that in many workflows this does not make sense, but I believe 
> that (as with 'git submodule update --rebase') there are some cases 
> where it does make sense, and I see no reason to support one, but not 
> the other.

We have a _lot_ of obscure things that are not supported by core Git, but 
are _very_ easy to add as _tiny_ add-on scripts by the user, without the 
need for "official" feature support.

Just like this one,
Dscho