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

Thomas Rast [off-list ref] writes:

quoted

#0. These will stay as is:

 $ git checkout mine               ;# switches to the branch
 $ git checkout $any_committish^0  ;# detaches

#1. These used to detach, but will create a local branch

 $ git checkout origin/next        ;# as if with -t
 $ git checkout xyzzy/frotz        ;# as if with -t (origin is not special)

Agreed, though I'm still in favour of a cleaner syntax for explicit
detaching.  (Cleaner in the sense that ^0 is documented as having a
completely different purpose and only works by accident.)

Oh, ^0 was just one way to make sure a committish is not a refname.  If
you have an abbreviated hexadecimal commit object name, that would also
detach, which should fall into category #0.  Sorry for the omission.

quoted

#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.

quoted

#3. These used to detach, but what should we do?

 $ git checkout v1.0.0             ;# detach, or refuse???

Refuse, on the grounds that the main goal here is not detaching unless
specifically told to.  (Having a branch called v1.0.0 is worse, as it
would just cause a lot of confusion and/or a refusal at the next
checkout.)

quoted

 $ git checkout origin/master      ;# detach, or refuse???

This seems to be the trickiest of them.  Maybe check out 'master', to
make the process repeatable.  Imagine, in your setting,

  git checkout origin/next           ;# creates 'next' as with -t
  git checkout -                     ;# back
  git checkout origin/next           ;# should go to 'next' again

Then again, that would trade the confusion of detaching for the
confusion of not checking out the exact commit that the user
specified.  Worse, 'next' could conceivably be tracking (as per
branch.next.merge) some entirely different branch, making the "Your
branch is behind..." message misleading.

As I said already in the thread, I think that is a misguided attempt to
half-hide the fact that there are origin/next (tracking branch) and next
(a fork of it), that are two separate entities.  It is misguided because
the user needs to understand and take advantage of the distinction to do
anything; in other words, it is not even an unnecessary complexity.

So I am very doubtful about the benefit of checking out 'master' when
the user explicitly tells us to check out 'origin/master', only because
the former forked from the latter.

Some that come to mind:

#3a. Other refs apart from tags that currently detach:

  git fetch origin master            ;# or even sillier, 'git fetch . master'
  git checkout FETCH_HEAD            ;# used to detach; refuse?

#3b. Full specifiers that currently detach:

  git checkout refs/heads/master     ;# could eventually attach
  git checkout heads/master          ;# same

I'd throw both of these into category #3.

Anything that is valid "ref" (i.e. what dwim_ref() groks) that is not
a remote tracking branch (which creates a corresponding local branch)
can refuse to avoid unintended detachment by newbies.

#0a. Should probably detach if the previous checkout was detached:

  git checkout -                     ;# detach if previous was detached?
  git checkout @{-1}                 ;# same

Perhaps.

So to recap, "git checkout $token" would:

 * If dwim_ref() groks $token, and

   - if it resolves to refs/heads/*, that is checking out a local branch;

   - if it resolves to refs/remotes/*, and if there is no corresponding
     local branch, create one forked from there, as if -t was given;

   - everything else we used to detach, but we refuse in 1.7.0, to make it
     harder for newbies to detach.

 * If check_ref_format() is happy with $token, get_sha1() does not grok
   $token, and there is only one ref of the form refs/remotes/$o/$token
   then we pretend as if -t $o/$token was given and create a local branch
   $token forked from it.

 * Otherwise, we always detach.

Note that "checkout -" and "checkout @{-4}" are part of dwim_ref() family.

Hi,

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

Thomas Rast [off-list ref] 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]

quoted

quoted

#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.

On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote:

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.

The similar suggestion that is less magical is to say something like
"there is no $X; maybe you meant $REMOTE/$X?".  Is there a reason not to
phase in the behavior, to make sure it is not doing unexpected things?
In other words:

  1. In v1.6.6, find all error-correcting candidates and print them as
     a suggestion (similar to what we do with "git foo").

  2. Then, if we all agree that it seems to be producing sane results,
     the next step is to turn the unambiguous cases into a DWIM (and
     leave the ambiguous ones with the "did you mean?" message).

Because right now I think there are a lot of hypothetical "maybe it
would be less convenient or more confusing in this instance", but we
don't have any data on how often those instances occur, or how actual
users might react. So doing step (1) would be a way of collecting some
of that data (will users say "stupid git, if you knew what I wanted, why
didn't you just do it?" or "stupid git, your suggestion is just
confusing me!").

-Peff

Hi,

On Tue, 13 Oct 2009, Jeff King wrote:

On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote:

quoted

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.

The similar suggestion that is less magical is to say something like
"there is no $X; maybe you meant $REMOTE/$X?".

At some point, trying to educate the user is not helpful but annoying.  If 
Git already knows what I want, why does it not do it already?  _That_ is 
the question I already hear in my ears.

Is there a reason not to phase in the behavior, to make sure it is not 
doing unexpected things?

Sure, I have nothing against that.  But just insisting on the current 
behavior, or on some behavior that is not helpful at all, well, is not 
really clever.

Note that I am fully aware that my "git checkout -t origin/master" DWIMery 
backfired quite badly.  So I am in the same boat.

In other words:

  1. In v1.6.6, find all error-correcting candidates and print them as
     a suggestion (similar to what we do with "git foo").

  2. Then, if we all agree that it seems to be producing sane results,
     the next step is to turn the unambiguous cases into a DWIM (and
     leave the ambiguous ones with the "did you mean?" message).

Because right now I think there are a lot of hypothetical "maybe it
would be less convenient or more confusing in this instance", but we
don't have any data on how often those instances occur, or how actual
users might react.

Oh, I do not want to spam the list with user experiences.  But I do have 
not only a faint idea how users react.  Thankyouverymuch.

So doing step (1) would be a way of collecting some of that data (will 
users say "stupid git, if you knew what I wanted, why didn't you just do 
it?" or "stupid git, your suggestion is just confusing me!").

I disagree.  It is not about collecting data.  We will not get any 
feedback from the affected people.  You know that, I know that.

The step (1) would help in the way that it is a smoother transition.

Ciao,
Dscho

On Tue, Oct 13, 2009 at 7:22 PM, Johannes Schindelin
[off-list ref] wrote:

At some point, trying to educate the user is not helpful but annoying.  If
Git already knows what I want, why does it not do it already?  _That_ is
the question I already hear in my ears.

Modify checkout so that the first commit while detached automatically
creates a branch. Perhaps the name is derived from the branch point,
or the user is prompted for a name.

This doesn't help with the original problem, which was that a user
attempted to checkout refs/remotes/origin/<name> by just saying 'git
checkout <name>' which I happen to think should work. A lot of what I
keep hearing in this thread seems to be in the vein of the perfect
being the enemy of the good.

That rambled a bit. Sorry.

j.

On Wed, Oct 14, 2009 at 01:22:26AM +0200, Johannes Schindelin wrote:

At some point, trying to educate the user is not helpful but annoying.  If 
Git already knows what I want, why does it not do it already?  _That_ is 
the question I already hear in my ears.

I am not entirely convinced that the suggested behaviors will result in
that user response, or a different one (like "why does git keep giving
me bad advice?"). Which is why I suggested data collection.

quoted

So doing step (1) would be a way of collecting some of that data (will 
users say "stupid git, if you knew what I wanted, why didn't you just do 
it?" or "stupid git, your suggestion is just confusing me!").

I disagree.  It is not about collecting data.  We will not get any 
feedback from the affected people.  You know that, I know that.

I don't agree. You are already talking about users complaining about
git's interface. Isn't that feedback? How do you hear those complaints
now?

I don't think they will come on the list and talk about it, but if we
release a version of git that has differing behavior and give it some
time to be used in the wild, we _will_ get feedback in the form of
blogs, complaints on other lists, word-of-mouth, etc.

Now maybe that is not a good idea in this instance, because that sort of
feedback may take several versions to appear, and we are talking about a
potential timetable of v1.7.0, which is probalby only two versions away.

-Peff