How to recover from a git mistake

Don't let an error in a git command wipe out days of work.
397 readers like this.
Bubble hands

Today my colleague almost lost everything that he did over four days of work. Because of an incorrect git command, he dropped the changes he'd saved on stash. After this sad episode, we looked for a way to try to recover his work... and we did it!

First a warning: When you are implementing a big feature, split it in small pieces and commit it regularly. It's not a good idea to work for a long time without committing your changes.

Now that we've gotten that out of the way, let's demonstrate how to recover changes accidentally dropped from stash.

My example repository, which has only one source file, main.c, looks like this:

Repository with one source file

It has only one commit, the initial commit:

One commit

The first version of our file is:

First version of the file

I'll start to code something. For this example, I do not need to make a big change, just something to put in the stash, so I will just add a new line. The git-diff output should be:

git-diff output

Now, suppose that I want to pull some new changes from a remote repository, but I'm not ready to commit my change. Instead, I decide to stash it, pull the remote repository's changes, then apply my change back to the master. I execute the following command to move my change to stash:

git stash

Looking into the stash with git stash list, I can see my change there:

Output of changes in our stash

My code is in a safe place and the master branch is clean (I can check this with git status). Now I just need to pull the remote repository changes, then apply my change on the master, and I should be set.

But I accidentally execute:

git stash drop

which deletes the stash, instead of:

git stash pop

which would have applied the stash before dropping it from my stack. If I execute git stash list again, I can see I dropped my change from the stash without applying it on the master branch. OMG! Who can help me?

Good news: git did not delete the object that contains my change; it just removed the reference to it. To prove this, I use the git-fsck command, which verifies the connectivity and validity of the objects in the database. Here's the output after I executed the git-fsck command on the repository:

Output after executing the git-fsck command on the repository

With the --unreachable argument, I asked git-fsck to show me the objects that are unreachable. As you can see, it showed no unreachable objects. After I dropped the changes on my stash, I executed the same command, and received a different output:

Output after dropping changes on stash

Now there are three unreachable objects. But which one is my change? Actually, I don't know. I have to search for it by executing the git-show command to see each object.

Output after executing the git-show command

There it is! The ID 95ccbd927ad4cd413ee2a28014c81454f4ede82c corresponds to my change. Now that I found the missing change, I can recover it! One solution is check out the ID into a new branch or apply the commit directly. If you have the ID of the object with your changes, you can decide the best way to put changes on the master branch again. For this example, I will use git-stash to apply the commit on my master branch again.

git stash apply 95ccbd927ad4cd413ee2a28014c81454f4ede82c

Another important thing to remember is git runs its garbage collector periodically. After a gc execution, you can no longer see the unreachable objects using git-fsck.

This article was originally published on the author's blog and is reprinted with permission. 

User profile image.
I'm José Guilherme Vanz, from south Brazil. Working as Software Engineer. I love Open Source and programming


I think it would be very interesting if the user could configure Git to always ask for confirmation before doing actions that could result in data loss (even if some are recoverable like shown here, most users will never find this out). Once I remember to have lost a whole commit and had to rewrite it all. I was just lucky that I still had parts of the code in my mind.

Good suggestion. You should bring this suggestion in the git community. Maybe, they can implement your idea.

In reply to by teresaejunior (not verified)

The only place you have no undo is git reset --hard where the working directory. Use git stash -u instead.

Good to know. Thanks for the tip. When I wrote this article, I didn't know that. So, I found a hard way solution. ;)

In reply to by Adam Dymitruk (not verified)

Interesting but why don't you use "git reflog"? It can save you from almost any situation.

Actually 'git stash" is _implemented_ using reflog, and dropping a stash entry means deleting entry from the reflog that implements stash.

If you meant reflog for 'master' or for 'HEAD' - yes, that's a good question.

In reply to by Jacopo (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.