6

So this is the fifth time this has happened in the past three weeks and I am really stumped as to why this keeps happening. This is the exact message I get when I do 'git status'

error: object file .git/objects/48/088f00d90b0d27de65336bb9ed9a75b0cfed33 is empty
fatal: loose object 48088f00d90b0d27de65336bb9ed9a75b0cfed33 (stored in .git/objects/48/088f00d90b0d27de65336bb9ed9a75b0cfed33) is corrupt

I've tried recommendations such as deleting the corrupt object, but then the same error comes up with another loose object. Every time I've done this, there ends up being around 30 loose objects which I have to delete and then it still gives me an error after all of the corrupt objects are gone.

Being the fifth time this happened, something has to be wrong with git or something related to it. I have tried re-installing git, but I still ended up with the corrupt objects. I am using a virtual machine running Ubuntu, if that would cause something like this, I don't know. I have also tried switching to Linux mint and I countered this problem as well.

In the end I have always just saved the changes to a text file, deleted my repository, pull fresh repository from git hub and then edit the changes back in. That works but it is time consuming and far from ideal. I'm not necessarily looking for a way to fix this, but rather what is causing it and how to prevent it from happening again.

Huub Mons
  • 149
  • 1
  • 11
  • What file system(s) are you using? Is the repo on the virtual drive of the VM or accessed via NFS/CFS or a loopback mount or a direct ext2/ext3/jfs/reiserfs/xfs/... mount of a local device on the host, or a SAN disk? Is the file system in question full, or close enough to it that it might hit full during certain operations? Any disk/filesystem errors in your messages/syslog files? – twalberg Aug 31 '12 at 17:25
  • I am using a virtual hard drive which is formatted to ext4 in which the repository is stored. The vhd's capacity is 100 GB and I'm only at like 20 GB so I am nowhere close to being full. No filesystem errors either... – Huub Mons Aug 31 '12 at 17:36
  • See this excellent answer, http://stackoverflow.com/a/12371337/23118, to more or less the same problem. – hlovdal Feb 08 '13 at 19:33

4 Answers4

3

Layman Way (Tested with GITHUB):

  1. Go to your project directory
  2. Show hidden files
  3. Delete the .git folder
  4. Clone your (remote) repo into a different directory
  5. Show hidden files
  6. Copy the .git folder
  7. Paste it into your old project directory
  8. Continue with normal operations: git add, git commit, git push

BONUS:
9. Sleep peacefully

Adam Beleko
  • 676
  • 7
  • 15
0

This should normally not happen, since git first writes the file content in a temporary file, and then renames the file to its final location. In practice, I did see empty Git object files due to a broken filesystem (VirtualBox's vboxsf, used for folder sharing, seems to be the guilty one whenever I saw people complaining about empty files like this).

Setting core.fsyncobjectfiles to true may help.

Matthieu Moy
  • 15,151
  • 5
  • 38
  • 65
0

Running git prune worked for me! You might lose your old local/inactive branches which origin does not have

git prune origin
Akshay Upadhya
  • 1
  • 1
  • 2
0

In my case I found that this error was caused by having my local repository on an NFS mounted filesystem. If the repository is on a local drive it works fine. I'm still looking to see if there's a workaround for the NFS issue - perhaps .gitignore for .nfs* files.

pbft
  • 41
  • 5