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

Jeff King [off-list ref] writes:

On Wed, Nov 04, 2009 at 07:41:28AM +0100, Sverre Rabbelier wrote:

quoted

On Wed, Nov 4, 2009 at 07:17, Tim Mazid [off-list ref] wrote:

quoted

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.

... 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.