Some weeks ago, I had quite an unusual issue with Git. In a repository I hadn’t used for quite a while, I simply wanted to see, if I had any changes, so I ran a git status on it with the following result:
$ git status
error: object file .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 is empty
error: object file .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 is empty
fatal: loose object 6eeab7d4770c705a0491cafbc95830af69d5c6a2 (stored in .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2) is corrupt
I’ve never experienced that before. Fortunately, Git offers some commands to check a Git repository, so I did a file system check:
$ git fsck --full
error: object file .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 is empty
error: unable to mmap .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2: No such file or directory
error: 6eeab7d4770c705a0491cafbc95830af69d5c6a2: object corrupt or missing: .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2
Checking object directories: 100% (256/256), done.
error: object file .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 is empty
error: object file .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 is empty
fatal: loose object 6eeab7d4770c705a0491cafbc95830af69d5c6a2 (stored in .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2) is corrupt
This gave me a bit more verbose information that one object was corrupt, but still no help in how to solve it, which Git usually gives you when using a command.
The Solution
With this new information, I was able to find a solution on Stack Overflow. I just had to delete the corrupt/empty file. In my case, it was really just this one file. In other repositories, there might be multiple files. To quickly delete them all, we can search the Git folder for all “empty” files and delete them:
$ find .git/objects/ -type f -empty | xargs rm
After this command, all corrupt files are missing from the repository. We can get them back by fetching the data from the remote:
$ git fetch -p
remote: Enumerating objects: 228, done.
remote: Counting objects: 100% (228/228), done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 210 (delta 121), reused 188 (delta 99), pack-reused 0
Receiving objects: 100% (210/210), 90.23 KiB | 2.65 MiB/s, done.
Resolving deltas: 100% (121/121), completed with 11 local objects.
Finally, we make another file system check to see if all errors are gone:
$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (221/221), done.
dangling blob c5446110414804bbba2a5316a3e996ff37666bb9
dangling blob 45dd1301284105bcfc7e183bc805b65bf1465f47
dangling blob 70376fcbe5060d0db11490249bed5b553c0d04cc
Conclusion
Usually, Git gives us quite useful error messages, when we do something wrong. In this case I had to research a bit but fortunately was not the first one to encounter this issue.
Our fix only worked without any losses, because we were able to fetch the deleted corrupt/empty objects from a remote. This is why I always advise people to always have their code in a remote repository as well, and commit and push often.