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, 08:44 UTC
- Message-ID
- <7v7huzznqy.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> 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/masterSorry, I had this as refs/heads/{master,mine} in my initial draft but removed the 'mine' branch by mistake; the first item in #0 does not make sense without it.
Show 28 quoted lines
> 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?