Re: [PATCH] Teach remote machinery about remotes.default config variable

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 13, 2008, 21:27 UTC
Message-ID: <alpine.LSU.1.00.0801132224540.8333@wbgn129.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v4pdislrf.fsf@gitster.siamese.dyndns.org>

Hi,

On Sat, 12 Jan 2008, Junio C Hamano wrote:

Show 17 quoted lines

> Mark Levedahl <mlevedahl@gmail.com> writes:
> 
> > Basically, I think an important (but not complete) test of the design
> > is that
> >
> >    git clone -o frotz git://frotz.foo.bar/myproject.git
> >    cd myproject
> >    git submodule init
> >    git submodule update
> >
> > work, with origin = frotz throughout the submodules, and with the
> > whole project correctly checked out even if the entire project was
> > rehosted onto a different server.
> 
> I like that.  This is a very good argument, especially because it 
> clarifies very well that the issue is not about "'submodule init' 
> misbehaves" but "fetch/pull/merge does not play well with clone -o".

FWIW I disagree.

I never understood why people want to complicate things by being able to name default _keys_ differently. Why not letting "origin" being the default being pulled from, and be done with it?

Besides, I _really_ do not understand why we have such a discussion in rc phase. There are _many_ more interesting discussions now that _also_ do not belong into a freeze phase.

Ciao, Dscho