5 ms·

> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. G

• atq2119 4y ago
  > 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.
• cryptonector 4y ago
  Never `git checkout -f` or `git reset --hard` unless you know you want to throw away extant changes from the workspace. That's it. Know that, live that, and you'll never lose work because of Git.
  • stu2b50 4y ago
    You can git reset --hard and still get your work back without much trouble. Resets just move the branch pointer back, after all.
    • cryptonector 4y ago
      Hard resets throw away extant changes in the workspace that are not in the index or committed. You can't find those changes in the reflog or stash.
    • remram 4y ago
      It also throws away changes from both the working copy and the staging area.
      • cryptonector 4y ago
        Only if --hard is given.
        • remram 4y ago
          Which is what we're talking about.
          • cryptonector 4y ago
            Right, so stop typing that at all. Instead use `git checkout -f` to throw away extant changes. The `-f`/`--force` option is a lot clearer in intent than `--hard`.
            • 4y ago
• nemetroid 4y ago
  > if you do 'git checkout [path]' The entire point of that command is to discard local changes. There is some risk of getting the different forms of checkout mixed up, though, so prefer using switch and restore instead. As far as I know, the only use case of checkout not covered by other commands is checking out a commit that doesn’t have a branch attached to it.
  • lisper 4y ago
    > The entire point of that command is to discard local changes. I think that's arguable, but it's neither here nor there. Someone who is not well versed in git arcana will be surprised that the level of risk associated with 'git checkout [branch]' is radically different from 'git checkout [directory]'. I think a lot of people will learn this the hard way, especially if they have been told "It is very hard to permanently lose work." It's not true. Permanently losing work is as easy as being careless with git checkout.
    • wizofaus 4y ago
      I haven't learned the hard way thankfully, but I certainly found it very surprising. It's not at all obvious, and the GUIs with git support call it something like "Undo changes" or "Revert" etc.
    • nemetroid 4y ago
      > Someone who is not well versed in git arcana will be surprised that the level of risk associated with 'git checkout [branch]' is radically different from 'git checkout [directory]'. I disagree that it's a difference in the level of risk. There's no "risk" that git checkout [path] will discard your uncommitted changes, it's a promise and a certainty. That said, I agree that the breadth of largely unrelated functionality smushed into git checkout is surprising, but it's also one of the few things about Git's user interface that actually has been addressed by new subcommands.