14

I did:

git init
git add .
git rm -rf dirname

Looking at other answsers, git reset --hard HEAD, git checkout -f and git reflog did not work, apparently because there is no HEAD to go back to, nor a commit to get the files back from.

Is there a way to get the files back?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
B Seven
  • 44,484
  • 66
  • 240
  • 385

8 Answers8

15

Warning: Running git prune without the -n option (1) will erase your unreachable data.

There may be a way, using git prune and git cat-file.

Running git prune -n will list which objects would be removed by pruning:

$ git prune -n
9cc84ea9b4d95453215d0c26489d6a78694e0bc6 blob
c315143703752ef4d11ca7d93f2c324872b2ebff blob

Each line corresponds to a deleted file.

Now, using git cat-file, we are able to restore the contents of the removed file to a new file:

git cat-file -p 9cc84ea9b4d95453215d0c26489d6a78694e0bc6 > restored-filename

(1) From the git prune docs:

NAME
git-prune - Prune all unreachable objects from the object database

OPTIONS
-n
--dry-run
Do not remove anything; just report what it would remove.

Anderson Vieira
  • 8,919
  • 2
  • 37
  • 48
  • 3
    This is the only answer that really helped! Thank you! – Maksim Kovalev Aug 20 '21 at 00:08
  • 1
    You are a LIFESAVER! After working on a project for 12 hours and attempting an initial commit, I accidentally ran `git rm -rf .` to backout a change. I honestly thought all my work was lost forever. Note to future self - ALWAYS start with an empty repo then add files as you go along! – giran Jan 08 '22 at 17:05
10

There is no way.

Usually, git rm checks the files have already been committed before deleting them, so you don't lose any of your work. However, using -f overrides this check.

In short:

  • Don't use -f.
  • Don't touch anything you haven't committed.
Lambda Fairy
  • 13,814
  • 7
  • 42
  • 68
3

if you haven't yet committed, you can recover the directory by doing:

git stash
git stash pop
git co dirname
J.caff
  • 31
  • 2
  • This is clearly the best answer that solves the problem presented. It should come with the warnings provided in the accepted answer to be the perfect answer – matt Dec 13 '22 at 13:03
2

Nope, as far as I know. I believe that git unlinks the files, just like doing rm -rf does. It doesn't matter to it whether it knows about the files or not, it will gladly nuke the directory. Really, your only recourse is to try to use a file recovery tool as if you had done rm -rf

Matt
  • 10,434
  • 1
  • 36
  • 45
2

If git is not tracking the dirname directory, it will not allow you to delete the directory with git rm -rf as it does not know about it. You will ( would have) get an error like

fatal: pathspec 'dirname' did not match any files

Only way you could have deleted is if you had done a git add . or git add dirname after the git init. If that is the case, your files are gone and you cannot get them back as it was never committed and git doesn't track it. It is as good as doing a rm -rf on a normal folder ( and can't recover unless you have backups)

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • Does it, though? I didn't test it, but I thought the -f flag will suppress that error. – Matt Mar 10 '12 at 05:19
  • Unless you use `-f`? That will "Override the up-to-date check.", whatever that means. – B Seven Mar 10 '12 at 05:20
  • @Matt - No it does not suppress that. `-f` in `git rm` is only to override up-to-date check. – manojlds Mar 10 '12 at 05:21
  • I just tested it on Git 1.7.5.4. `git rm -rf` would not touch an unstaged directory, but it will happily purge a staged but not committed one. – Lambda Fairy Mar 10 '12 at 05:31
1

git reset --hard helped while deletion was not commited yet and, generally speaking, deletion was interrupted by Ctrl+Z

vladkras
  • 16,483
  • 4
  • 45
  • 55
0

git stash is the command which worked for me.

Suprabhat Kumar
  • 645
  • 7
  • 13
0

first type "git stash"

then "git stash pop"

after you will see a list of deleted files. copy file names one by one and use

"git restore filename..." to discard changes in the working directory

user21136331
  • 31
  • 3