Re: [PATCH] gitk: disable checkout of remote branch

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2009, 18:03 UTC
Message-ID: <7vhbtai2uy.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091104072709.GC24263@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> On Wed, Nov 04, 2009 at 07:41:28AM +0100, Sverre Rabbelier wrote:
>
>> On Wed, Nov 4, 2009 at 07:17, Tim Mazid <timmazid@hotmail.com> wrote:
>> > So instead of invoking 'git checkout REMOTE/BRANCH', do 'git checkout -b
>> > BRANCH REMOTE/BRANCH'.
>> 
>> Automagically doing 'git checkout -t remote/branch' when asked to do
>> 'git checkout remote/branch' was suggested earlier on the list and I
>> think there was even a patch that implemented it, not sure what the
>> outcome of the series was. I do remember that Peff was annoyed by it
>> at the GitTogether though so it might be a bad idea.
>
> It's in 'next' now.

Isn't it quite different? What's in 'next' for 1.7.0 is to guess the user's intention when:

 - he says 'git checkout BRANCH'; and

 - BRANCH does not yet exist; and

 - BRANCH does not name a commit so the request cannot be to detach HEAD
   at some commit (like REMOTE/BRANCH); and

 - there is a unique REMOTE that has BRANCH.

The user wants to check out his own BRANCH (the request lacks REMOTE to start with) but such a branch does not exist yet, and there is only one sensible commit to start that new branch, hence we DWIM it and helpfully run "git branch -t BRANCH REMOTE/BRANCH" automatically before performing "git checkout BRANCH" that was asked.

We never claim to allow checking out the remote tracking branch itself. The new guessing is only about a local branch that does not exist yet.

Show 15 quoted lines

> ... I am still not convinced that we won't later regret leaving the
> stale local branch sitting around, or that users won't find it confusing
> to see:
>
>   $ git checkout foo
>   Branch foo set up to track remote branch foo from origin.
>   Switched to a new branch 'foo'
>
>   ... time passes ...
>
>   $ git checkout foo
>   Switched to branch 'foo'
>   Your branch is behind 'origin/foo' by 1 commit, and can be fast-forwarded.
>
> (i.e., you do the same thing, but get two very different results,...

I think this is primarily because the way this DWIM is totally silent in the transcript is misleading. If you explain it the way I outlined above, I do not think there is any confusion. That is, there is no way for the user to get confused if the command sequence were like so:

   $ git branch -t foo origin/foo
   Branch foo set up to track remote branch foo from origin.
   $ git checkout foo
   Switched to a new branch 'foo'

   ... time passes ...

   $ git checkout foo
   Switched to branch 'foo'
   Your branch is behind 'origin/foo' by 1 commit, and can be fast-forwarded.

It could just be a matter of telling what we are doing a bit more explicitly when this DWIM kicks in. How about this?

   $ git checkout foo
   (first forking your own 'foo' from 'origin/foo')
   Branch foo set up to track remote branch foo from origin.
   Switched to a new branch 'foo'

In any case, I do not think the DWIM would kick in when you try to detach at remote branch head. I did not check gitk code to find out the exact command line it uses, but I do not think it runs "checkout BRANCH". The command needs to be at least "checkout REMOTE/BRANCH" to work the way it does now with any released version of git, and I would not be surprised if paulus was cautious enough to have spelled it as "refs/REMOTE/BRANCH" to avoid any potential ambiguity issues.