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

From: Johan Herland <johan@herland.net>
Date: May 19, 2009, 08:45 UTC
Message-ID: <200905191045.39108.johan@herland.net>
In-Reply-To: <alpine.DEB.1.00.0905191015560.26154@pacific.mpi-cbg.de>

On Tuesday 19 May 2009, Johannes Schindelin wrote:

Show 23 quoted lines

> 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)?

I still don't see any reason why one should be added (--rebase), and not the other (--merge).

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

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net