"Use git checkout."
"And how should I create a branch?"
"Use git checkout."
"And how should I update the contents of a single file in my working directory, without involving branches at all?"
"Use git checkout."
"Use git checkout."
"And how should I create a branch?"
"Use git checkout."
"And how should I update the contents of a single file in my working directory, without involving branches at all?"
"Use git checkout."
It actually makes sense if you learn the full command but makes zero sense when you google individual common operations and then they thought "this command should also have a shorthand to create branches" I suppose
I call this "hacker tunnel vision". It is a state afflicting a lot of programmers at the top of their game when it comes to writing end-user API and documentation. It can be summarized by "it is so obvious that people will think I'm mocking them for explaining this"
`git checkout` for restoring files is dumb though, but as others have mentioned the UX has been improved with `git restore`
Git checkout covering multiple usecases makes sense to me, I've never thought, hey this is used for all these different things they should be separate. I think, hey, this tool is always checking out a hash and a path.
The fact that can be a branch or a commit is entirely inconsequential. If it irks you it's because you think there is a difference between a branch and a commit then you're likely lacking some fundamental understanding about git.
I'd even argue that hiding this fact is what makes all of the other CVS a pain in the ass to use because they are trying so hard to hide the truth from their users.
For example SVN is strictly a linear snapshot of a single tree.