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:
|
1 2 3 4 5 6 7 |
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
|
1 2 3 4 5 6 |
# git fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (2218/2218), done. dangling commit 5ae478cea3aa6f42cc8fe865c9fc26b35ea9e15d dangling commit b657b57b65f6fc4ffea1c25c77ff62c94471d41a dangling commit 1c9ef0ff781f812f506ca1d18ef4af4a90a4938d |
Aby rozwiązać ten problem należy ustawić git-a za pomocą tych komend:
|
1 2 3 4 5 6 |
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:
|
1 2 |
#vim /etc/gitlab/gitlab.rv omnibus_gitconfig['system'] = { "pack" => ["windowMemory = 100m", "packSizeLimit = 100m", "threads = 1", "window = 0"]} |
A następnie: gitlab-ctl reconfigure
