Git – Błąd „repository corruption”

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 1c9ef0ff781f812f506ca1d18ef4af4a90a4938d

Aby 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

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*