On Tue, Jun 08, 2010 at 09:29:58AM +0200, Clemens Buchacher wrote: > Let's assume the user "just wants to check out branch X." Such a > use case has been mentioned previously in this thread. So they say > "git checkout X", and voila, they get what they wanted. > > It did what they meant it to do. Everybody is happy. But not for > long. > > Because the next time they "just want to check out branch X," they > will remember, it's time for "git checkout X." But what's this? > This is not what they wanted. It does not have the latest changes > on branch X! Didn't they do the same thing they did last time? > > No they did not, because last time they _created a branch_. > Eventually, if they are lucky, they will learn in #git that they > were supposed to "git merge <remote>/X." And they will think "WTF? > Why do I have to _merge_? And what's this business about remotes? > Why is git is so complicated?" FWIW, I made this same complaint at the GitTogether, and the response I got is that git does help the user along through the second "checkout". You get something like: $ git checkout foo Branch private 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 5 commits, and can be fast-forwarded. Now you can certainly argue that a clueless user won't know what to do with those messages, but it is not entirely true that git leaves them without any advice. Perhaps we could lessen the "wtf" moment in your example above by making that advice better. -Peff -- 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