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

[Thomas Rast <trast@student.ethz.ch>]

Junio C Hamano wrote:
> 
> What it means is that -t was a broken attempt to help the users at the UI
> level, and I can surely see that.
> 
> So we need the set of new rules, say, for 1.7.0 release.  A strawman?

I feel somewhat uneasy commenting on this because I have a history of
writing just-barely-workable UIs.  That being said:

> Assume that these are the only refs that exist:
> 
>     refs/remotes/origin/{master,next,nitfol}
>     refs/remotes/xyzzy/{frotz,nitfol}
>     refs/heads/master
>     refs/tags/v1.0.0
> 
> #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.)

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

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

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

> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we
> started refusing to detach in case #3, as people who want to detach can
> always suffix ^0 or ~0 to make it a general committish.
> 
> Did I cover all cases?

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

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

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

-- 
Thomas Rast
trast@{inf,student}.ethz.ch