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

From: Thomas Rast <trast@student.ethz.ch>
Date: Oct 13, 2009, 08:51 UTC
Message-ID: <200910131051.47117.trast@student.ethz.ch>
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 5 quoted lines

> 
> 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:

Show 16 quoted lines

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

Show 5 quoted lines

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

Show 5 quoted lines

> 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