0

What is the "best practice" recommended method of recovering files in this scenario:

A user modifies files in her Linux workspace. She runs a "git add" and stages them. She does not commit them. Time passes. She accidentally removes all of the modified files using '/bin/rm' (not 'git rm').

Now, a 'git status' reported them as 'deleted' (correct). It recommended running a "git reset HEAD file" and "git checkout -- file" for each (incorrect). This resulted in the latest (HEAD) versions of each being left in her workspace, not those containing her staged changes. Aside from running a 'git fsck' and trying to resolve the various SHA references, what should the user do now to recover the changes she originally staged ?

Mike Goddard
  • 506
  • 7
  • 14
  • 1
    Possible duplicate of [In Git, how can I recover a staged file that was reverted prior to committing?](https://stackoverflow.com/questions/11094968/in-git-how-can-i-recover-a-staged-file-that-was-reverted-prior-to-committing) – Ian MacDonald Oct 17 '18 at 19:54
  • See [this answer](https://stackoverflow.com/a/45502615/2708650) about [git-recover](https://github.com/ethomson/git-recover). – Ian MacDonald Oct 17 '18 at 19:55
  • Thanks! Yeah, the 'git-recover' script/blog has some very useful information, so that may very well address it. I'm still concerned that the 'git status' recommendation caused the dangling objects in the first place though. – Mike Goddard Oct 17 '18 at 20:32
  • Keep in mind that the `git status` recommendation is in response to the question "how do I get my file back?", not your specialized (and uncommon) use case of "how do I get my modified and not-yet-checked-in file back?" The `rm` command caused the dangling objects, not the `git reset` or `git checkout`. – Ian MacDonald Oct 17 '18 at 20:36
  • Ahh ... OK, gotcha. Yeah, that makes more sense. I wanted to believe git was doing the Right Thing with that recommendation :-) – Mike Goddard Oct 17 '18 at 20:51

1 Answers1

1

If the files were added but not committed then they initially sat in the index/stage. After using rm the second recommendation (i.e. git checkout -- <file>) given by git status was correct, as it checks the file out from the index and into working directory.

I assume that you have run both of the commands you listed, in this order:

git reset HEAD <file>
git checkout -- <file>

Unfortunately, this caused the reset command to first remove staged files from the index, bringing it back to an earlier committed version and discarding those changes. And then the checkout put this file in the directory.

You can easily test this:

git init
echo "my content" > somefile.txt
git add somefile.txt
git commit -am "commit"
echo "more content" >> somefile.txt
git add somefile.txt
rm somefile.txt
git status
git checkout -- somefile.txt

Right now git-recover may be an option, but I have never used it.

Piotr Broda
  • 46
  • 3
  • OK yeah, we actually ran through a very similar scenario as you mentioned to confirm "git checkout -- foo.c" was the command we wanted to use in the first place, not the 'reset HEAD'. Chalk it up to a learning curve :-) The engineer is recovering the files using 'git-fsck' and 'git show'. – Mike Goddard Oct 17 '18 at 21:11