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

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@student.ethz.ch> writes:

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

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

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

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.