3 ms·

Checkout is fine; it makes sense when you realize that the entire point of checkout is that it updates your current working tree to whatever you instruct it to.

Checkout is fine; it makes sense when you realize that the entire point of checkout is that it updates your current working tree to whatever you instruct it to. What "whatever" is: it's anything that git can understand as a reference; branch names (including those on remotes), commit IDs, HEAD and offsets (carets) on top of any of them. ie. If you do "checkout master" it will checkout your working tree to the master branch. If you do "checkout HEAD", you get whatever's the current HEAD of your repository (in practice, this discards your changes). Checkout can also do a partial checkout on a specific part of your working tree; "checkout [filename]" makes it so that you update that specific file to how it is on whatever you point it at. The only weirdness is "checkout -b [branch]" making a new branch and switching you to it. It's a bit syntactically off/breaks the previous thing, but makes a lot of sense when you realize that your average workflow will combine git branch and git checkout anyway (since you're pretty much always making a branch to them work on it.) Git switch and restore both feel like syntactic sugar that doesn't really help enough to warrant the mental switch of going from checkout to switch/restore. (Not to mention that checkout and restore do different things; restore also merged some functionality from git reset, a command whose main purpose is to update the index.)

nayuki 2y ago
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.
fargle 2y ago
can't upvote this enough. the only (minor) issue i see is the checkout -b shortcut feature is unnecessary and could be confusing if learned before a canonical approach that emphasizes that those are two things - checking something out to the working tree and creating a named branch pointing at it. other than that, contrary to sibling comments, no the rest of checkout is fine. yes it has guardrails that are perhaps not 100% consistent, but i don't think they every could be. but guardrails or not, when you say `git checkout <versionish>` it trys to checkout the <versionish> version to the working tree. it's highly intuitive that `git checkout <versionish> <filename>` it doesn't do the whole tree, but only that file (excellent for reverting a single file). i don't want git checkout to be called git switch or any other nonsense. git checkout checks out a version and that is terminology common with just about every cm tool ever. git reset is a hot mess. the blog post should be about that mess, not checkout.

nayuki 2y ago

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.

fargle 2y ago

can't upvote this enough. the only (minor) issue i see is the checkout -b shortcut feature is unnecessary and could be confusing if learned before a canonical approach that emphasizes that those are two things - checking something out to the working tree and creating a named branch pointing at it. other than that, contrary to sibling comments, no the rest of checkout is fine. yes it has guardrails that are perhaps not 100% consistent, but i don't think they every could be. but guardrails or not, when you say `git checkout <versionish>` it trys to checkout the <versionish> version to the working tree. it's highly intuitive that `git checkout <versionish> <filename>` it doesn't do the whole tree, but only that file (excellent for reverting a single file). i don't want git checkout to be called git switch or any other nonsense. git checkout checks out a version and that is terminology common with just about every cm tool ever. git reset is a hot mess. the blog post should be about that mess, not checkout.