15 ms·

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"

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.

hnarn 3y ago
That does not sound right at all, I’m pretty sure there’s a warning when you try to checkout a branch that would override local unstaged changes. I might be wrong but I’d like some proof.
- Izkata 3y ago
  Checkout is also used for reverting changes to unstaged files.
- chlorion 3y ago
  In some repo you have, make some changes to files that are tracked. Git status will show you "changes not staged for commit: <more stuff>". Run "git checkout .", and check the status command again, it will be in a clean state. >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") >git checkout . Updated 1 path from the index >git status On branch feature/redacted nothing to commit, working tree clean
- alex_smart 3y ago
  git checkout is overloaded and has two use cases. git checkout $branch is safe, git checkout $file_or_folder_name will help you shoot yourself in the foot.
astrobe_ 3y ago
There must be something you do terribly wrong if you believe it happened to you in normal use.
- mb7733 3y ago
  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
  - astrobe_ 3y ago
    That's as unfortunate as 'rm *' (and good to be aware of BTW), but doing this deliberately doesn't qualify as "normal use" for me.
    - alex_smart 3y ago
      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.
      - astrobe_ 3y ago
        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.
        alex_smart 3y ago
LtWorf 3y ago
That's not what checkout does.
- chlorion 3y ago
  In a repo with unstaged changes, running "git checkout ." will checkout files from a specific commit into the worktree and clobber your unstaged changes. By default it probably uses HEAD as the commit to checkout from. You 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.
chronial 3y ago
That's the reason why it was replaced by two separate, more sensible commands: git switch for switching branches etc, which is safe, and the inherently dangerous git restore for reverting changes in your working directory.
- alex_smart 3y ago
  It wasn't replaced, the other two commands were added to the cli. 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 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.

hnarn 3y ago

That does not sound right at all, I’m pretty sure there’s a warning when you try to checkout a branch that would override local unstaged changes. I might be wrong but I’d like some proof.

Izkata 3y ago
Checkout is also used for reverting changes to unstaged files.
chlorion 3y ago
In some repo you have, make some changes to files that are tracked. Git status will show you "changes not staged for commit: <more stuff>". Run "git checkout .", and check the status command again, it will be in a clean state. >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") >git checkout . Updated 1 path from the index >git status On branch feature/redacted nothing to commit, working tree clean
alex_smart 3y ago
git checkout is overloaded and has two use cases. git checkout $branch is safe, git checkout $file_or_folder_name will help you shoot yourself in the foot.

astrobe_ 3y ago

There must be something you do terribly wrong if you believe it happened to you in normal use.

mb7733 3y ago
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
- astrobe_ 3y ago
  That's as unfortunate as 'rm *' (and good to be aware of BTW), but doing this deliberately doesn't qualify as "normal use" for me.
  - alex_smart 3y ago
    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.
    - astrobe_ 3y ago
      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.
      - alex_smart 3y ago

LtWorf 3y ago

That's not what checkout does.

chlorion 3y ago
In a repo with unstaged changes, running "git checkout ." will checkout files from a specific commit into the worktree and clobber your unstaged changes. By default it probably uses HEAD as the commit to checkout from. You 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.

chronial 3y ago

That's the reason why it was replaced by two separate, more sensible commands: git switch for switching branches etc, which is safe, and the inherently dangerous git restore for reverting changes in your working directory.

alex_smart 3y ago
It wasn't replaced, the other two commands were added to the cli. 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.