Re: What's cooking in git.git (May 2009, #02; Sun, 17)

> On Tuesday 19 May 2009, Johannes Schindelin wrote:
> > 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
> 
> Does that mean you're also opposed to 'git submodule update --rebase' 
> (which is already in 'next', and is even Signed-off-by yourself)?

> Dropping both would at least be consistent from core Git's POV, but 
> following that thread, we should probably also drop "git pull" (which is 
> just a simple wrapper around "git fetch" and "git merge"), and maybe 
> also "git clone" (which can easily be scripted, using "git init", "git 
> remote", "git fetch" and "git branch")...