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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2009, 07:16 UTC
Message-ID: <7vljjf226t.fsf@alter.siamese.dyndns.org>
In-Reply-To: <200910130836.57011.trast@student.ethz.ch>

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

Show 8 quoted lines

>> Or can't you go the other way, say
>> 
>> 	git checkout -t $remote_tracking
>> 
>> to create a local branch forking from the named remote tracking branch?
>
> Sure, but we already have that and we still failed to fix the users,
> so FWIW, I think Dscho's right and we should try fixing the UI next.

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?

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)

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

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

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

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?