The poster is talking about when you do something like this: `git checkout .` That wipes out all unstaged changes on tracked files in the current directory
In my career, it has already happened more than once. And definitely not deliberately.
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.
No question this design is questionable and I'm glad I learned about it before falling victim of it. I read that they introduced git-switch and git-restore as a way to avoid such pitfalls.
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.
While I agree changing branches is the most common use-case for git checkout, it's far from the only "normal" one. The form that updates files to match revisions is actually mentioned first in the man page:
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.
Now that `git switch` exists, one could argue that this is the main use case for `checkout` and the other one could be deprecated.
