Czasami, kiedy pracujemy na dużych projektach możemy natknąć się na błąd związany z korupcją repozytorium. Nie zawsze chodzi tutaj o zepsusie/utratę repozytorium. Czasami jest to błąd spowodowany niemożliwością wykonania czynności zaplanowanych przez git-a z powodu zbyt dużego repozytorium i zbyt krótkiego czasu na wykonanie go. Jest to z reguły spowodowane błędną konfiguracją parametrów 'windowsMemory’ i 'SizeLimit’.
Ten błąd może wyglądać tak:
Cloning into 'test_repo'...
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
fatal: early EOF: 41%
emote: aborting due to possible repository corruption on the remote side.
fatal: index-pack failed
Aby upewnić się, że faktycznie nie mamy do czynienia z prawdziwym uszkodzeniem repozytorium możemy użyć fsck
# git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (2218/2218), done.
dangling commit 5ae478cea3aa6f42cc8fe865c9fc26b35ea9e15d
dangling commit b657b57b65f6fc4ffea1c25c77ff62c94471d41a
dangling commit 1c9ef0ff781f812f506ca1d18ef4af4a90a4938dAby rozwiązać ten problem należy ustawić git-a za pomocą tych komend:
git config --global pack.windowMemory "100m"
git config --global pack.SizeLimit "100m"
git config --global pack.threads "1"
git config --global pack.window "0"
Rozwiązanie dla GitLab:
Pierwszy raz na problem ten natrafiłem w środowisku GitLab-a korzystając z dużego prywatnego repozytorium, a powyższe komendy nie zadziałają w tym środowisku ponieważ GitLab korzysta z plików .rb, aby tworzyć pliki konfiguracyjne, dlatego należy:
#vim /etc/gitlab/gitlab.rv
omnibus_gitconfig['system'] = { "pack" => ["windowMemory = 100m", "packSizeLimit = 100m", "threads = 1", "window = 0"]}A następnie: gitlab-ctl reconfigure