Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Tue, 13 Oct 2009, Junio C Hamano wrote:

> Thomas Rast <trast@student.ethz.ch> writes:
> 
> [this was probably quoted from Junio, Dscho doesn't have time to go back 
>  and check, but then, this was not specified in the quoted mail]
>
> >> #2. These are allowed only when unambiguous and there is no local branch yet.
> >> 
> >>  $ git checkout next               ;# ok
> >>  $ git checkout frotz              ;# ok (origin is not special)
> >>  $ git checkout nitfol             ;# not ok (ambiguous and origin is not special)
> >
> > I'm weakly leaning towards refusing all three, as the user should be
> > required to explicitly say a remote branch should be involved.
> >
> > (Weakly because there's also a certain DWIM advantage to 'git checkout
> > sometopic'...)
> 
> I thought this was the primary point of what Dscho has been advocating.

To be honest, I was not advocating anything except being more open to 
users' problems, because we _did_ grow a large user base, way beyond the 
Linux developers (whom we can always harrass and tell to RTFM).

Just to re-add my well-known stance: consistency is a good thing.  So if 
things are ambiguous, we can be consistent in saying so and refusing to 
DWIM.  And if things are _not_ ambiguous, we can be consistent in just 
DWIMming what the user most probably meant.

If the user just typed random things in the hope that it works, we cannot 
do anything about it anyway.

So in my opinion, we should DWIM "git checkout $X" to mean "git checkout 
-b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and 
no other refs/remotes/$OTHER/$X.

Likewise "git checkout $REMOTE/$X".

But, in my opinion, if there is refs/heads/$X and refs/remotes/origin/$X, 
and the user says "git checkout origin/$X", we should tell the user that 
there are the options to checkout $X and origin/$X^0 (the latter only if 
the user really intended to detach her HEAD), but not try to DWIM 
anything.

IMHO it is obvious that Hannes' suggestion to fast-forward $X and check it 
out in said scenario has some benefits in certain situations, but dramatic 
downsides in others.

But I need to drive some very important point home in this thread: 1.7.0 
was announced to break some old-time habits in favor of a better 
user-interface.  We _need_ to use this opportunity fully.

Even if that means that a few fingers have to be retrained.  Because 
retraining a few for the benefit of an easier time with the many others 
is Just Worth It.

Or in other words: logic clearly dictates that the needs of the many 
outweigh the needs of the few.

Ciao,
Dscho

P.S.: In case certain persons, ahem, think that I am applying the "Many 
Outweigh Few" principle to the time involved in top-posting and 
"forgetting" to cut quoted text to what is actually addressed: yes, you 
could not be more correct.  And I no longer believe that this goes without 
saying.