Git restore deleted files - bad default revision 'HEAD'

Question

I just started using git. I ran the commands:

git init

Then I did:

git add app/controllers/*

(To add all the controllers.)

Then I decided to remove those, so I tried :

git rm app/controllers/*

This gave me an error saying there was some unsaved changes or something, so I had to use the -f flag to force the delete. Now knowing exactly what I was doing, I retyped the command: git rm -f app/controllers/*

Now all my controllers I've been working on for the past weeks are deleted and I don't know how to get them back. I unfortunately had no other back up, which I know is incredibly stupid.

I tried looking on Google. It there are a few commands I tried to run, but whatever I type it says that :

bad default revision 'HEAD'.

Any help recovering the past weeks of work would be incredibly appreciated!

Answer 1

Presuming you haven't done any permanently destructive commands since your original mistake you should be able to recover your files.

What you can't recover however is the names of the files. Git will store the content, but not the path/name.

So use git fsck to find dangling blobs, then cat the results out and redirect the contents to new files.

me@myvm:/scratch $ mkdir rmtest
me@myvm:/scratch $ cd rmtest
me@myvm:/scratch/rmtest $ mkdir app
me@myvm:/scratch/rmtest $ cd app
me@myvm:/scratch/rmtest/app $ mkdir controllers
me@myvm:/scratch/rmtest/app $ cd controllers 
me@myvm:/scratch/rmtest/app/controllers $ echo "2 weeks worth of work" > foo
me@myvm:/scratch/rmtest/app/controllers $ cd ../../
me@myvm:/scratch/rmtest $ git init
Initialized empty Git repository in /scratch/rmtest/.git/
me@myvm:/scratch/rmtest  (master)$ git add app/controllers/*
me@myvm:/scratch/rmtest  (master)$ git rm app/controllers/*
error: the following file has changes staged in the index:
    app/controllers/foo
(use --cached to keep the file, or -f to force removal)
me@myvm:/scratch/rmtest  (master)$ git rm -f app/controllers/*
rm 'app/controllers/foo'
me@myvm:/scratch/rmtest  (master)$ ll
total 0
me@myvm:/scratch/rmtest  (master)$ git fsck 
notice: HEAD points to an unborn branch (master)
Checking object directories: 100% (256/256), done.
notice: No default references
dangling blob f9a0e5002ae9f9a854ecf50560c40b3b0a7ec7bc
me@myvm:/scratch/rmtest  (master)$ git cat-file -p f9a0e5002ae9f9a854ecf50560c40b3b0a7ec7bc
2 weeks worth of work

Answer 2

The add command doesn't add files into the repository. It adds file to the staging area/index. I'm not what you were trying to do when you rm'ed them. Git warns you about them not being committed but then you forcefully removed them using the -f flag which removes the files from the index as well. Now your files are gone.

However, you did add them to the index once so the repository does have blobs for them (assuming you've just done this recently). A low level solution is to go into the .git/objects directory and look for loose objects. You'll find things like this.

{GIT_DIR!}% pwd
/tmp/bar/.git/objects
{GIT_DIR!}% tree .
.
├── 85
│   └── bfe46bc8180ef0f145d8abf946879a524df4a8
├── info
└── pack

3 directories, 1 file
{GIT_DIR!}%            

Now you do something like git show 85bfe46bc8180ef0f145d8abf946879a524df4a8 (notice that the first two characters are the directory name and the rest are the file name. This will display the contents of that blob which will be one of your files. You'll have to read it and figure out which file it was and then redirect the output as appropriate.

I've made this point before. Git is not very user friendly. It's a power tool so a detailed reading of the documentation before you start using it is highly advisable.