Remote: Aborting due to possible repository corruption

I have a large repository with some relatively large files in it. Total repository size is +/- 20GB with some files that are several GB.

I have found that I can push to the repository, but not clone. Ultimately it appears that this is a memory issue which was confirmed by watching docker process statistics which show it consuming all available memory before dying, but I have not found a solution and/or maybe I am applying it incorrectly.

The Error

error: pack objects died of signal 9
error: git upload-pack: git-pack died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.

fatal: early EOF
fatal: fetch-pack: invalid index-pack output
Gittea: internal error

git did not exit cleanly (exit code 128)…405s

Server Configuration

  • Gitea v1.17 run via Docker
  • RAM: 1GB
  • Processor: 1 Core
  • OS: Ubuntu
  • SSH Shim setup

Fix References

Can someone explain how to apply this to the docker instance? If I execute the bash within docker using the interactive flag I can add the git flags, but then when the docker container restarts they are gone. So how do I persist these settings? Then, do I need to re-commit the repository for them to take effect?

Additionally, do I need to apply any settings to the primary server, or only within the “git” configuration of the docker instance?

Ideally I would like to retain compression because it shrinks things significantly but I am limited on resources (RAM). This is a small repository on a VPS used by only a couple people for reference.

Thank you.

To apply the fix from StackOverflow post, you can either edit [repository.root]/user/repo.git/config for just the one large repo or edit /var/lib/gitea/.gitconfig for all repositories and add:

[pack]
         windowMemory = 100m
         SizeLimit = 100m
         threads = 1

Alternatively, add window = 0 instead of windowMemory, SizeLimit, … to disable packing entirely, but note that cloning will be less efficient.