Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Oct 13, 2009, 18:39 UTC
- Message-ID
- <alpine.LNX.2.00.0910131358000.32515@iabervon.org>
- In-Reply-To
- <7vljjf226t.fsf@alter.siamese.dyndns.org>
On Tue, 13 Oct 2009, Junio C Hamano wrote:
Show 47 quoted lines
> Thomas Rast <trast@student.ethz.ch> 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.I suspect that a very common pattern for people who follow trees for testing and such or who only develop in topic branches is:
$ git clone ... $ git checkout origin/next $ git fetch origin $ git checkout origin/next
For people who use topic branches extensively:
$ git fetch origin $ git checkout origin/next (test, find issues, maybe make changes) $ git checkout -b topic $ git commit (send changes)
Some people (IIRC, including Linus):
$ git checkout origin/next (work) $ git commit $ git checkout -b topic
In all of these cases, the user will get a misleading "next" local branch; in Linus's case, this branch ends up with commits from a topic branch.
For that matter, even the intended user would have problems with your suggestion:
$ git clone ...
$ git checkout origin/next (do some next stuff) $ git checkout origin/master (do some master stuff) $ git checkout origin/next
On the second cycle, either git refuses or does something actively confusing to this user, and the user has to learn the difference between local branches and remote branches on the *second* cycle. IMHO, it's much better to make users learn things at the point when they don't think they know how to use the system, rather than when they think they understand it and are just trying to get things done.
-Daniel *This .sig left intentionally blank*