Jeff King <peff@xxxxxxxx> writes: > On Wed, Nov 04, 2009 at 07:41:28AM +0100, Sverre Rabbelier wrote: > >> On Wed, Nov 4, 2009 at 07:17, Tim Mazid <timmazid@xxxxxxxxxxx> 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. > ... 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. -- 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