git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.
It will take decades before git checkout will actually get replaced by git switch/restore in all the git books, tutorials and search results. Most normal users will keep learning and using git checkout in the meanwhile.
I understand why they can't actually deprecate existing commands. The git command is used in far too many existing shell scripts across thousands of companies.
I would argue that this is actually a fundamental deficiency of the "unix way" of doing things, where the same command is meant to be used both by human beings and in automated workflows. Automated workflows require backwards compatibility. Humans need easy to use interfaces that don't allow them to easily shoot themselves in the foot. The same tool cannot serve both needs.
>git status
On branch feature/redacted
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: redacted.py
no changes added to commit (use "git add" and/or "git commit -a")
Updated 1 path from the index
On branch feature/redacted
nothing to commit, working tree cleanYou can checkout files and directories from completely unrelated commits and even unrelated repos!
I have used this to checkout specific useful files from other projects. It's a little nicer than just copying them in, because you can keep the repo tracking branch updated and keep checking out updates, and you can easily compare your file to theirs, and see what changes they have made to the file.
There are many ways this can happen accidentally. You could be trying to checkout a branch and tab complete your way into a folder name instead. You could be typing alt/esc + . with the intent of getting last argument of previous bash command, keyboard glitches and you end up with . instead.
Just because it hasn’t happened to you yet, you shouldn’t discount the experience of others. That’s like saying you have never messed up dd yet, so there are no problems with dd’s design.
But. I once messed up badly with something else once, makefiles. I was kind of overconfident and end up screwing myself by telling something to write its output to my source files by mixing up $< and $@ somehow. Another time I accidentally overwrote a file with a simple output redirection. These two days I learned to be cautious with those commands. Same way that I always stop 2 seconds to reread my command line when I use rm.
Fool me once, shame on the tool; fool me twice, shame on me.
Well, that's what OP was referring to, but in such a "click-bait-y" way.
DESCRIPTION
Updates files in the working tree to match the version in the index or the specified tree. If no pathspec
was given, git checkout will also update HEAD to set the specified branch as the current branch.