10

I had used the command git checkout -- $(git ls-files -m) to undo a git rm on some files. However, I had modified some other files without committing them, and these files have been reverted to their previous commit, losing the uncommitted changes.

Is there a way to get these changes back?
I imagine not with git as the changes weren't added to git. On a Mac if that helps.

Thanks Tom

holmeswatson
  • 969
  • 3
  • 14
  • 39
  • 1
    Check `git reflog`. Might be helpful in your situation. It's like a list of restore points you can reset to. http://git-scm.com/docs/git-reflog – Tim Apr 09 '14 at 10:24
  • 2
    If you did a `git add` of the modified contents, those are now stored in the repository and will show up as "dangling blob"s (use `git fsck --lost-found` to get file contents, but the names are gone). If not ... well, if Time Machine backed them up you might be able to get them from there. Otherwise they are probably gone. – torek Apr 09 '14 at 10:34
  • 1
    I didn't git add and time machine doesn't have the changes :( – holmeswatson Apr 10 '14 at 10:38
  • 1
    This question could/should be generalized to "Does git checkout really silently overwrite uncommitted changes?" And the answer is still "yes" in 2018 (just tested with 2.11)... A mere accidental/forgetful `git checkout .` and good bye pending work, in EACH file! :-o No warning, not a word. As if that could be the happiest possible result. (And the internet seems complicitly silent about this, just see how your question got zero answers. :) Or, worse: I've even seen *reasoning* for it, equivalent to saying `format c:` or `rm -r` should not ask, as you deliberately issued the command... :) ) – Sz. Mar 20 '18 at 14:19

2 Answers2

3

"Does git checkout really silently overwrite uncommitted changes?"
And the answer is still "yes" in 2018 (just tested with 2.11)

It is true in August 2019, with Git 2.23, except there is now a more explicit git restore command

A simple git restore . would also restore the working tree silently, from the index content (so if the files were modified but not added to said index, their changes would still be lost)

But at least there is no confusion possible between checkout of files and of branch.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    I don't suppose there's any use my asking a Stack Overflow question like "why does git checkout myfile overwrite changes to myfile without warning?" I'd just be whining about something we all know, wouldn't I? – matt Jan 12 '20 at 00:12
  • @matt Eventually, `git checkout` will be retired (obsolete). Only `git switch` and `git restore` will remain. – VonC Jan 12 '20 at 00:21
  • And does git restore behave better? My git is too old to test. – matt Jan 12 '20 at 00:26
  • @matt That is what I describe in https://stackoverflow.com/a/57066072/6309: it can still override a file content, but it is *explicit*: you want to *restore* the content of a file. – VonC Jan 12 '20 at 00:27
  • 1
    Cool, thx. My gut feeling is that this is still wrong: just as you couldn't switch branches if your uncommitted changes would be clobbered, you shouldn't be able to restore to another commit's version without at least being warned if that would wipe out your uncommitted / unadded changes. But maybe I just expect too much hand-holding. :) – matt Jan 12 '20 at 00:58
2

By default you can't get it back, but you may be lucky in such an emergency situation and be able to retrieve a file that you accidentally clobbered by git checkout filename in the following ways:

  • You may still have the file buffered in a text editor (for me I have found in my BBEdit text editor that, if I had it open, I can do an
    undo to get the file back (because it tends to be loaded to the
    current version if the file on disk is changed), and then save.
  • Also if you have continuous backup running you might also be able to get back a version you edited. For example Apple Time Machine might
    have a version from only a short while ago.
Timothy C. Lethbridge
  • 339
  • 2
  • 3