I accidentely said git rm -r .
. How do I recover from this?
I did not commit.
I think all files were marked for deletion and were also physically removed from my local checkout.
EDIT: I could (if I knew the command) revert to the last commit. But it would be a lot better if I could just undo the git rm -r .
. Because I am not really sure what I did after the last commit and before the git rm -r .
.
-f
to git rm
git won't have removed any files that had staged or unstaged changes so a git reset; git checkout .
should recover everything.
git restore
: git restore -s@ -SW -- .
. See my answer below.
git reset HEAD
Should do it. If you don't have any uncommitted changes that you care about, then
git reset --hard HEAD
should forcibly reset everything to your last commit. If you do have uncommitted changes, but the first command doesn't work, then save your uncommitted changes with git stash
:
git stash
git reset --hard HEAD
git stash pop
I git-rm'd a few files and went on making changes before my next commit when I realized I needed some of those files back. Rather than stash and reset, you can simply checkout the individual files you missed/removed if you want:
git checkout HEAD path/to/file path/to/another_file
This leaves your other uncommitted changes intact with no workarounds.
git rm
rather than an entire recursive git rm -r
. For a full recursive delete, the other solutions may be better, depending on the amount of files removed.
To regain some single files or folders one may use the following
git reset -- path/to/file
git checkout -- path/to/file
This will first recreate the index entries for path/to/file
and recreate the file as it was in the last commit, i.e.HEAD
.
Hint: one may pass a commit hash to both commands to recreate files from an older commit. See git reset --help
and git checkout --help
for details.
git rm
operation without wiping out other uncommitted changes.
Update:
Since git rm .
deletes all files in this and child directories in the working checkout as well as in the index, you need to undo each of these changes:
git reset HEAD . # This undoes the index changes
git checkout . # This checks out files in this and child directories from the HEAD
This should do what you want. It does not affect parent folders of your checked-out code or index.
Old answer that wasn't:
reset HEAD
will do the trick, and will not erase any uncommitted changes you have made to your files.
after that you need to repeat any git add
commands you had queued up.
git alias.co="checkout"
so that git co
does checkout.
If you end up with none of the above working, you might be able to retrieve data using the suggestion from here: http://www.spinics.net/lists/git/msg62499.html
git prune -n
git cat-file -p <blob #>
git prune -n
, I got many lines, those lines are either tree
or blob
or commit
, and I fill out all the hash string of blob
, and I try to use the second command to git cat-file -p <blob #>
, and I still can't find the lost file. My situation is quite simple, I have create a new file named a.cpp
, and I add this file to the index, and later I use the git rm -f
to remove this file, and I see that a.cpp
get lost.
git rm -f
deleted file, I'm not sure why the previous test does not works, thanks!
undo git rm
git rm file # delete file & update index
git checkout HEAD file # restore file & index from HEAD
undo git rm -r
git rm -r dir # delete tracked files in dir & update index
git checkout HEAD dir # restore file & index from HEAD
undo git rm -rf
git rm -r dir # delete tracked files & delete uncommitted changes
not possible # `uncommitted changes` can not be restored.
Uncommitted changes
includes not staged changes
, staged changes but not committed
.
git rm -rf
, as that may delete untracked or staged (only) files as well.
git rm -rf file
and git rm -rf dir
will not delete any untracked files.
If you've committed and pushed the changes, you can do this to get the file back
// Replace 2 with the # of commits back before the file was deleted.
git checkout HEAD~2 path/to/file
There are some good answers already, but I might suggest a little-used syntax that not only works great, but is very explicit in what you want (therefor not scary or mysterious)
git checkout <branch>@{"20 minutes ago"} <filename>
Get list commit
git log --oneline
For example, Stable commit has hash: 45ff319c360cd7bd5442c0fbbe14202d20ccdf81
git reset --hard 45ff319c360cd7bd5442c0fbbe14202d20ccdf81
git push -ff origin master
I had an identical situation. In my case the solution was:
git checkout -- .
With Git 2.23+ (August 2019), the proper command to restore files (and the index) woud be to use... git restore
(not reset --hard
or the confusing git checkout
command)
That is:
git restore -s=HEAD --staged --worktree -- .
Or its abbreviated form:
git restore -s@ -SW -- .
If you execute the command git rm -r --cached .
on a repo with changes that are not staged (so not committed either), you can undo the operation (unstage from deletion) with the command git restore --staged .
So in a nutshell, to undo git rm -r --cached .
you only need to run git restore --staged .
I had exactly the same issue: was cleaning up my folders, rearranging and moving files. I entered: git rm . and hit enter; and then felt my bowels loosen a bit. Luckily, I didn't type in git commit -m "" straightaway.
However, the following command
git checkout .
restored everything, and saved my life.
Success story sharing
git reset --hard HEAD
destroys any useful changes you have made in parent directories of the current working directory.