git checkout my-commit -- my-file and git reset --soft/hard/mixed become git restore --source my-commit --worktree --staged my-file. The --source my-commit flag tells us which version to restore, and --worktree and --staged tell us whether this new version should be placed in the working tree, the staging area, or both.
The author takes the time to remind us what each command does before describing the new feature, so that everybody can follow along. That is an act of caring, and much appreciated <3
Thanks for your kind words: I’m excited about git switch and git restore, too. If nothing else, they make clearer what is (and I hope that I have illustrated) a quite overloaded command. That’s nobody’s own fault, of course, it has simply grown with Git over the many years.
Your last point especially warms my heart. I like to use these blog posts both as a chance to write about the new and exciting features in Git, as well as to introduce some older commands or tips to both existing and new Git users. It’s a big tool, so I often have to remind myself of some of the details when writing.
New features often are hard to untangle without understanding the old ones, too, so I’m happy that you enjoyed it. Thanks for reading :-).
one dedicated command for each of git checkout’s two roles
Actually, “behind the scene” it is exactly the same command. git checkout just set current working tree and HEAD to given ref. The new commands for sure are nice addition, but in general the “git checkout does so many things” isn’t that much true.
Lovely! Some things that made me happy in this announcement:
git checkout
’s two roles:git checkout my-branch
becomesgit switch my-branch
git checkout my-commit -- my-file
andgit reset --soft/hard/mixed
becomegit restore --source my-commit --worktree --staged my-file
. The--source my-commit
flag tells us which version to restore, and--worktree
and--staged
tell us whether this new version should be placed in the working tree, the staging area, or both.Thanks for your kind words: I’m excited about
git switch
andgit restore
, too. If nothing else, they make clearer what is (and I hope that I have illustrated) a quite overloaded command. That’s nobody’s own fault, of course, it has simply grown with Git over the many years.Your last point especially warms my heart. I like to use these blog posts both as a chance to write about the new and exciting features in Git, as well as to introduce some older commands or tips to both existing and new Git users. It’s a big tool, so I often have to remind myself of some of the details when writing.
New features often are hard to untangle without understanding the old ones, too, so I’m happy that you enjoyed it. Thanks for reading :-).
Some constructive criticism: It could be made a bit easier to skim. Headings, bolded keywords, perhaps.
Actually, “behind the scene” it is exactly the same command.
git checkout
just set current working tree andHEAD
to given ref. The new commands for sure are nice addition, but in general the “git checkout
does so many things” isn’t that much true.