5 ms·

> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. I

> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. It can do that, if you explicitly run it with the options to checkout a specific path. But why would you do that if it's not what you want?

amcoy37 4y ago
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.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
lisper 4y ago
> It can do that, if you explicitly run it with the options to checkout a specific path. Fair point. I've update my comment to clarify. > But why would you do that if it's not what you want? Because sometimes it is what you want. The point is, if you happen to do it when it's not what you want, you're hosed. So it is simply not true that "It is very hard to permanently lose work." It is, in fact, quite easy under certain not-uncommon circumstances.
- atq2119 4y ago
  Fair point. There probably should be standard advice along the lines of "if in doubt, make a 'wip' commit before you do anything". That's good advice even beyond using git itself.
compiler-guy 4y ago
"Just don't make a mistake" is a pretty bad strategy.
- chronometry888 4y ago
  But "save your changes before running a command that can clobber" is a pretty good strategy.
  - kjeetgill 4y ago
    Agreed though. I always start with teaching people. If you git add + git commit + git branch BACKUP everything you can very safely do anything you want. If you get confused it's trivial to get to a clean state by git reset --hard. If you give people a way to get to a clean slate it removes a significant amount of the learning curve. In my experience, push/pull/fetch/log/diff are easy enough it's only really merge/rebase management that gets people caught up. Giving people a short fuck up -> undo -> retry cycle lets people learn pretty quick.
auraham 4y ago
IIRC mercurial creates backup (.bak) files when restoring a file. As a result, you can keep changes in .bak files even after (accidentally) doing a `git checkout -- file` in mercurial. Git does not have that feature.

amcoy37 4y ago

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.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

lisper 4y ago

> It can do that, if you explicitly run it with the options to checkout a specific path. Fair point. I've update my comment to clarify. > But why would you do that if it's not what you want? Because sometimes it is what you want. The point is, if you happen to do it when it's not what you want, you're hosed. So it is simply not true that "It is very hard to permanently lose work." It is, in fact, quite easy under certain not-uncommon circumstances.

atq2119 4y ago
Fair point. There probably should be standard advice along the lines of "if in doubt, make a 'wip' commit before you do anything". That's good advice even beyond using git itself.

compiler-guy 4y ago

"Just don't make a mistake" is a pretty bad strategy.

chronometry888 4y ago
But "save your changes before running a command that can clobber" is a pretty good strategy.
- kjeetgill 4y ago
  Agreed though. I always start with teaching people. If you git add + git commit + git branch BACKUP everything you can very safely do anything you want. If you get confused it's trivial to get to a clean state by git reset --hard. If you give people a way to get to a clean slate it removes a significant amount of the learning curve. In my experience, push/pull/fetch/log/diff are easy enough it's only really merge/rebase management that gets people caught up. Giving people a short fuck up -> undo -> retry cycle lets people learn pretty quick.

auraham 4y ago

IIRC mercurial creates backup (.bak) files when restoring a file. As a result, you can keep changes in .bak files even after (accidentally) doing a `git checkout -- file` in mercurial. Git does not have that feature.