Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
>> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html