0

When pulling my repos as usual (via a short C program which pulls many repos, no matter whether changes occurred), one of them printed the following message:

error: object file .git/objects/eb/4384d0e2460629d912635ec622beb979024316 is empty
error: object file .git/objects/eb/4384d0e2460629d912635ec622beb979024316 is empty
fatal: loose object eb4384d0e2460629d912635ec622beb979024316 (stored in .git/objects/eb/4384d0e2460629d912635ec622beb979024316) is corrupt
fatal: The remote end hung up unexpectedly

The same message (sans the last line) was printed upon executing git status in the repository.

This question is not about how to restore data or anything like that. It's about understanding how this happened.

The repository only has 1 remote and only I use this remote (via several machines). I work directly on master in this repo and there are no other branches. The remote is accessed via ssh. 35 repos were pulled at that time and only this one repo broke.

It appears that the last change in this repository was made on the machine where the error occurred and was already committed and pushed to the remote.

I'm guessing this from the facts that latest commit in the remote is something I would have done on the machine whose repo broke and that the working directory after it broke doesn't contain any changes as git status reports a clean repo if I clone again from the remote and copy the working directory of the broken repo over to the fresh clone. Unfortunately, I can't use git log on the broken repo as it only prints the above-mentioned error message (sans the last line, of course).

When does a repo break like this? To me, it seems like the repo was in the perfect condition for absolutely nothing to happen.

Should it matter: The broken repo is in my home folder on an Ubuntu 16.04 (Kernel 4.8.0-58-generic) laptop which uses an ext4 partition and Ubuntu's default home folder encryption (eCryptfs).

This is the source code of the program I used to pull: https://pastebin.com/bBTz4vH2

UTF-8
  • 575
  • 1
  • 5
  • 23

1 Answers1

0

The error message usually caused by the git operation aborted abruptly.

You just need to remove the empty object 4384d0e2460629d912635ec622beb979024316 in .git/objects/eb folder of your local git repo. Then run git commands (such as git status or git pull) to check if it works normally.

Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • I didn't press any key combinations when the program ran. I added the C program I used for pulling to the question. It starts a new thread for each repo but I don't see my system's RAM usage increasing significantly. The process's memory stays below 1 MB, most of the git instances just determine that their respective repos are already up to date, and a few ones pull something, but generally stay below 1 MB of RAM usage, too. I don't see my system running out of process slots or anything like that, and even if it did, wouldn't it just take a bit longer? So what are the likely causes for this? – UTF-8 Jul 24 '17 at 15:34
  • Since it can't be reproduce, so it's hard to say. But it may also caused by operating the repo at the same time. – Marina Liu Jul 25 '17 at 08:54
  • Do you mean concurrent access of a single repo by more than one git process? [According to the answers to this question](https://stackoverflow.com/questions/13039150/are-concurrent-operations-possible-with-git-repositories), git is safe-to-use concurrently, except for `git gc`. If this hints you something about the reason: That object (`eb4384d0e2460629d912635ec622beb979024316`) is what HEAD points to. HEAD should already have pointed to it prior to pulling as this object was created during the last commit which occurred on the machine where the error occurred. – UTF-8 Jul 25 '17 at 12:12
  • Yes, concurrent access for a git repo can work good for most times, but it may cause git repo stop working by accident and I met once before. – Marina Liu Jul 26 '17 at 08:31