`git checkout -b` is one of the few things that I actually think git's default CLI got wrong. The primary thing that is doing is creating a branch, checking it out is kind of tangential in a way; I think that it should be `git branch -c`
I feel strongly that `git checkout file` is correct though. What that operation is doing is taking something out of the DAG and putting it into the working tree. It's the same deal, the only difference is instead of pulling a tree object (associated with a commit) from the DAG into the working tree, you are instead pulling a glob. It makes intuitive sense to me that these two operations would be accessed through the same command. Furthermore, using the name 'revert' would make much less sense in the rather frequent case that you want to pull a blob from a commit that is not the current HEAD. Is it really "reverting" if I am pulling a file from a future commit in another branch into my working tree? I don't think naming commands after less powerful concepts is a good design decision.
I feel strongly that `git checkout file` is correct though. What that operation is doing is taking something out of the DAG and putting it into the working tree. It's the same deal, the only difference is instead of pulling a tree object (associated with a commit) from the DAG into the working tree, you are instead pulling a glob. It makes intuitive sense to me that these two operations would be accessed through the same command. Furthermore, using the name 'revert' would make much less sense in the rather frequent case that you want to pull a blob from a commit that is not the current HEAD. Is it really "reverting" if I am pulling a file from a future commit in another branch into my working tree? I don't think naming commands after less powerful concepts is a good design decision.