7 ms·

Accidentally running a git command in the wrong folder is pretty easy to do at the command line. I was, at one point, in the habbit of running "git checkout ."

Accidentally running a git command in the wrong folder is pretty easy to do at the command line. I was, at one point, in the habbit of running "git checkout ." after writing some experimental code. Several times a day, or however often. So of course, I once accidentally ran that command in the wrong repo and obliterated some pending changes that hadn't been commited.

dotancohen 4y ago
How is that git's fault? I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key. I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.
- eropple 4y ago
  I dunno - I can tell zsh to are-you-sure me about an `rm -rf *`, git seems like it should be able to do similarly. Or, as Mercurial does, back up overwritten files to .bak. These are pretty light asks.
  - sagarm 4y ago
    The sole purpose of git checkout -- file is to overwrite the file you explicitly listed. There should not be a confirmation by default.
- Someone 4y ago
  I don’t see anybody here claiming that’s git’s fault. But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.
  - nemetroid 4y ago
    Using the command specifically designed to permanently discard work seems ”very hard” to me.
    - Someone 4y ago
      But it’s inconsistent in that. git checkout existing_branch complains with “error: Your local changes to the following files would be overwritten by checkout”* and abort, git checkout existing_directory overwrites files. That’s what makes it easy to make that mistake, and lose data. It’s safe to use until it suddenly isn’t.
      - nemetroid 4y ago
        I just don't understand why someone would do git checkout existing_directory if they don't want to overwrite files, since that is all the command does.

dotancohen 4y ago

How is that git's fault? I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key. I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.

eropple 4y ago
I dunno - I can tell zsh to are-you-sure me about an `rm -rf *`, git seems like it should be able to do similarly. Or, as Mercurial does, back up overwritten files to .bak. These are pretty light asks.
- sagarm 4y ago
  The sole purpose of git checkout -- file is to overwrite the file you explicitly listed. There should not be a confirmation by default.
Someone 4y ago
I don’t see anybody here claiming that’s git’s fault. But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.
- nemetroid 4y ago
  Using the command specifically designed to permanently discard work seems ”very hard” to me.
  - Someone 4y ago
    But it’s inconsistent in that. git checkout existing_branch complains with “error: Your local changes to the following files would be overwritten by checkout”* and abort, git checkout existing_directory overwrites files. That’s what makes it easy to make that mistake, and lose data. It’s safe to use until it suddenly isn’t.
    - nemetroid 4y ago
      I just don't understand why someone would do git checkout existing_directory if they don't want to overwrite files, since that is all the command does.