"Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch." Well, of course the

"Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch." Well, of course they both seem the same if you use the word "checkout" in the explanation for "checkout." But "rolling back changes in a file" and "switching the current branch I'm developing in" aren't that close anymore. The word itself might mean multiple things, but that doesn't imply it's a good idea to use it in both meanings. "In fact I mentioned in another comment that I always thought `git branch` could do the switching itself rather than checkout... I just don't think it's a problem. I know I'm working with a file or a branch, so I just know what will happen." But evidently there are people who do think it's a problem. Also, the argumentation is that this would prevent mistakes from being destructive. When you know what you want to do, and it does it, it's not a mistake. When you want to do one thing, but the other one happens for any reason (bash completion was one of the mentioned ones) you don't know it. "It doesn't matter that the name is the same since it's function depends on context." It depends on the type of its argument. A simple "git checkout foo" is indistinguishable. I'm just a bit astounded by the amount of contra to this simple proposal to an existent problem.