When you git add
a file, it will add that file to the object database and place the object information in the staging area. When you run a git reset
, the file is removed from the index, but it is not removed from the object database. As a result, you can examine the object database for objects that are "dangling".
For example:
If I create a new file and git add
it:
% echo "new file" > newfile.txt
% git add newfile.txt
% git ls-files --stage
100644 40ee2647744341be918c15f1d0c5e85de4ddc5ed 0 file.txt
100644 3748764a2c3a132adff709b1a6cd75499c11b966 0 newfile.txt
And then I reset, notice that newfile.txt
disappears from the index:
% git reset --hard origin/mybranch
% git ls-files --stage
100644 40ee2647744341be918c15f1d0c5e85de4ddc5ed 0 file.txt
However, the file remains in the object database, and can be recovered. The easiest way to do this is to download and install the git-recover
program in interactive mode:
% git recover -i
Recoverable orphaned git blobs:
3748764a2c3a132adff709b1a6cd75499c11b966 (Thu 15 Jun 2017 12:20:22 CEST)
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
> veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
> commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
Recover this file? [y,n,v,f,q,?]:
git-recover
looks for files in the object database that are not committed (or in the index). You can find out more about git-recover
in the blog post announcing it.