4

I was using git for the first time, I had a directory with several programs written in it and did the following steps

  1. I did git add .
  2. then git commit, then it i got a message Aborting commit due to empty commit message.
  3. Then i thought, let me commit group of files under common message. So i thought of removing all the added files.
  4. So i did git rm -r -f
  5. When i do a ls i have lost all my code. Is there any way that i can get them back, to my foolishness i don't have backup copy even.

Things that i have followed till now

I googled out some found some of the command but they are not working

git stash if i type this command i get

fatal: bad revision 'HEAD' fatal: bad revision 'HEAD' fatal: Needed a single revision You do not have the initial commit yet

git reset HEAD, if i type this command i get

Fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

I really need to get those files back!

Steps that i followed to create GIT

  1. mkdir BareRepo
  2. In BareRepo Directory i did git init, git status, git config --bool core.bare true
  3. Then i cloned the BareRepo git clone BareRepo/ Programs/
  4. In the Programs directory i did all the above said thing
JackWhiteIII
  • 1,388
  • 2
  • 11
  • 25
Manu
  • 5,534
  • 6
  • 32
  • 42
  • What do you see if you do `git status`? –  Jul 21 '13 at 14:49
  • Not a duplicate of [How to revert a “git rm -r .”?](http://stackoverflow.com/questions/2125710/how-to-revert-a-git-rm-r), original poster hasn't committed anything to his repo yet, it has no commits. –  Jul 21 '13 at 14:51
  • possible duplicate of [How to undo git rm -rf dirname without a first commit?](http://stackoverflow.com/questions/9644119/how-to-undo-git-rm-rf-dirname-without-a-first-commit) –  Jul 21 '13 at 14:56

2 Answers2

6

You may be able to recover the files from the aborted commit

Based on the observation of @the-malkolm.

From the information in the question, there are no commits, and the files were not tracked at any time. As such git does not really know about any of the files that have been deleted.

That said however, there is hope. Simply because you attempted to commit your files before deleting them, there is a phantom commit floating around with all of your files in it.

Here's an example:

$ git init
Initialised empty Git repository in /tmp/so/.git/
$ echo "find this text" > README.md 
$ git add README.md 
$ git commit -v 
Aborting commit due to empty commit message.
$ git rm -rf .
rm 'README.md' 
$ git status
# On branch master
# 
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

The above simulates the events in the question, and ordinarily this is the time to start rewriting the code again. There is no commit, the file is gone.

Identify that aborted commit

However inspecting the .git repository yields some information:

$ tree .git/objects/
.git/objects/
├── 91
│   └── 9cdf847a6af7c655c8de1d101385f47f33e0f9
├── d6
│   └── 7d51abe2521dcd00cec138b72f5605125c1e41
├── info
└── pack

There are objects in the git repository despite there being no commits. It's necessary to identify which of the two objects is the tree:

$ git ls-tree 919cdf
fatal: not a tree object
$ git ls-tree d67d51
100644 blob 919cdf847a6af7c655c8de1d101385f47f33e0f9    README.md
$

The first reference is the blob representing the README.md file - there will be one blob per file in the repository, the second in this example is the tree reference.

Recreating the working copy

Once the tree hash has been identified, it can be used to rebuild the index with read-tree:

$ git read-tree d67d51abe2521dcd00cec138b72f5605125c1e41
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   README.md
#
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    README.md
$

At this time, the working copy is empty but the lost files are staged for commit.

Commit them:

$ git commit -m "phew"

And checkout to match the committed state of the repository:

$ git checkout .
$ ls
README.md

And then, all files exist and have been committed.

Community
  • 1
  • 1
AD7six
  • 63,116
  • 12
  • 91
  • 123
  • The original poster could try recovering the deleted files from disk, but not through Git. Maybe he should try ask on how to do so on [Super User](http://superuser.com/). –  Jul 21 '13 at 14:57
  • 3
    If anything was ever added to the staging area than it's still in the repo until git-gc is run. – the.malkolm Jul 21 '13 at 15:48
  • 1
    @the.malkolm that.. is an excellent point, going to investigate. – AD7six Jul 21 '13 at 16:03
  • git cherry-pick $(echo "recovered" | git commit-tree d67d51abe2521dcd00cec138b72f5605125c1e41) – the.malkolm Jul 21 '13 at 16:27
  • The above steps only work in the checkout where you executed the commit, and the `git rm -rf .` . If you clone again, the objects won't exist _in that checkout_ to be found. – AD7six Jul 22 '13 at 06:21
  • @AD7six : I have cloned the bare repo, in that case i am not able to recover the deleted files,when i do git ls-tree on both the node i get fatal: not a tree object – Manu Jul 22 '13 at 06:22
-4

I am not sure this would work 100% but certainly worth a try I think:

git reflog is your command

reflog records every action you perform inside git...so I am betting on this.

reflog will produce a list of commands that you performed on your repo

To recover your work, go through the log that was produced by reflog and do a git reset --hard HEAD@{<x>}

.. substitute x with the number that defines state you want to like to be at...

....that should reset your repo back to original state (hopefully)

Vikram
  • 4,162
  • 8
  • 43
  • 65
  • 2
    The original poster didn't make any commits in his repo yet, so this won't work. –  Jul 21 '13 at 14:46