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:
opensource.com
It has only one commit, the initial commit:
opensource.com
The first version of our file is:
opensource.com
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:
opensource.com
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 stashLooking into the stash with git stash list, I can see my change there:
opensource.com
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 dropwhich deletes the stash, instead of:
git stash popwhich 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:
opensource.com
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:
opensource.com
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.
opensource.com
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 95ccbd927ad4cd413ee2a28014c81454f4ede82cAnother 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.
6 Comments