it-swarm.it

Git pull fallisce con l'errore di header bad pack

git pull fallisce con il seguente errore

remote: Counting objects: 146, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
error: git upload-pack: git-pack-objects 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: protocol error: bad pack header

Qualche idea su come tirare con successo? 

22
deimus

Le righe che iniziano con remote vengono emesse da git in esecuzione sul sistema remoto. L'errore:

fatal: unable to create thread: Resource temporarily unavailable

... suggerisce fortemente che hai esaurito la memoria sul server, cosa che può succedere se hai:

  1. Un repository con un sacco di file di grandi dimensioni, che possono causare il re-packing di prendere un sacco di memoria.
  2. Memoria virtuale limitata - in generale o solo per quell'account a causa dell'impostazione ulimit

Un suggerimento qui è di limitare la quantità di memoria che l'imballaggio può richiedere accedendo al sistema remoto (come l'utente che git gira come) e facendo:

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1" 
47
Mark Longair

Attenzione: se vedi questo errore con Git 2.19.1, questo è previsto, e documentato in git-for-windows/git problema 1839 : "git gc si blocca al 33% degli oggetti di conteggio" (che riporta un APPCRASH sia per git gc, ma anche for git pull), a causa di un mutex utilizzato in "git pack-objects", che non è stato inizializzato correttamente e ha causato "git repack" per eseguire il dump di core su Windows.

Come menzionato nel numero:

Colpisce più di solo gc. Ho colpito anche una variante con pull:

$ git pull
remote: Enumerating objects: 3548, done.
error: git upload-pack: git-pack-objects died with error.
fatremote: aborting due to possible repository corruption on the remote side.
al: git uploadf-pack: aborting due to possible repository corruption on the remote side.
atal: protocol error: bad pack header

Questo problema è stato risolto in Git 2.20 (Q4 2018).
Vedi commit 34204c8 , commit 9308f45 , commit ce498e0 (16 ott 2018) di Johannes Schindelin (dscho) .
(Fuso da Junio ​​C Hamano - gitster - in commit 620b00e , 30 ott 2018)

pack-objects (mingw): inizializza packing_data mutex nel punto corretto

In 9ac3f0e (pack-objects: risoluzione dei problemi di prestazioni durante il riempimento di grandi delta, 2018-07-22, Git v2.19.0-rc1), è stato introdotto un mutex che viene utilizzato per proteggere la chiamata per impostare la dimensione delta. Questo commette anche codice aggiunto per inizializzarlo, ma in un punto non corretto: in init_threaded_search(), mentre la chiamata a oe_set_delta_size() (e quindi a packing_data_lock()) può avvenire nella catena di chiamate check_object() <- get_object_details() <- prepare_pack() <- cmd_pack_objects(), che è molto prima la funzione prepare_pack() chiama ll_find_deltas() (che inizializza la ricerca filettata).

Un'altra spia che il mutex è stato inizializzato in un punto non corretto è che la funzione per inizializzarla vive in builtin /, mentre il codice che usa il mutex è definito in un file di intestazione libgit.a.

1
VonC

Aggiornamento: questa risposta era un suggerimento di modifica alla risposta di Mark Longair, che ora ha aggiornato la sua risposta con la denominazione corretta.

In effetti, pack.SizeLimit non è corretto, è pack.packSizeLimit.

Quando ho aggiunto questa opzione, ha funzionato per me :)

Ho dovuto impostarlo sia nei repository locali che in quelli remoti.

0
SylafrsOne