git checkout is not fine. git checkout <commit> requires a clean working tree, and will change HEAD to the specified <commit>. git checkout [<commit>] <paths>

git checkout is not fine. git checkout <commit> requires a clean working tree, and will change HEAD to the specified <commit>. git checkout [<commit>] <paths> does not require a clean working tree, will replace the specified paths (i.e. files or directories), and does not change HEAD. These are extremely different behaviors. I agree with the article that git switch vs. git restore are better replacements. Since you bring up the topic of git reset, I also disagree with what you said; I don't think its main purpose is to update the index; rather, it is to update the current branch's pointer to an arbitrary commit with the possibility of orphaning children (unlike git commit or git merge, which never lose children). Factually speaking, git reset can update just the branch (--soft), the branch and then index (--mixed), or the branch then index then working tree (--hard). Of course, if you perform git reset and stay at the current HEAD commit, then you have the choice of updating just the index, or the index and the working tree.