tag - Git pull falla con error de encabezado de paquete defectuoso

git tag name

Question

git pull falla con el siguiente error

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

¿Alguna idea de cómo tirar con éxito?

Answer 1

Advertencia: si ve este error con Git 2.19.1, esto se espera y se documenta en git-for-windows/git número 1839 : " git gc bloquea al 33% de los objetos contados" (que informa un APPCRASH para git gc , pero también para git pull ), debido a un mutex utilizado en "git pack-objects", que no se inicializó correctamente y provocó que " git repack " volcara el núcleo en Windows.

Como se menciona en el tema:

Afecta más que solo gc . Golpeé una variante con pull también:

$ 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

Esto se ha corregido en Git 2.20 (Q4 2018).
Consulte commit 34204c8 , commit 9308f45 , commit ce498e0 (16 de octubre de 2018) por Johannes Schindelin ( dscho ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 620b00e , 30 de octubre de 2018)}

pack-objects (mingw): inicializa la packing_data en el lugar correcto

En 9ac3f0e ( pack-objects : arreglar problemas de rendimiento al empaquetar grandes deltas, 2018-07-22, Git v2.19.0-rc1), se introdujo un mutex que se usa para proteger la llamada para establecer el tamaño delta. Esta confirmación incluso agregó código para inicializarlo, pero en un lugar incorrecto: en init_threaded_search() , mientras que la llamada a oe_set_delta_size() (y por lo tanto a packing_data_lock() ) puede ocurrir en la cadena de llamada check_object() <- get_object_details() < - prepare_pack() <- cmd_pack_objects() , que es mucho antes de que la función prepare_pack() llame a ll_find_deltas() (que inicializa la búsqueda de hilos).

Otro indicio de que el mutex se inicializó en un lugar incorrecto es que la función para inicializarlo vive en builtin /, mientras que el código que usa el mutex se define en un archivo de encabezado libgit.a .

Answer 2

Las líneas que comienzan con el remote se emiten desde git que se ejecuta en el sistema remoto. El error:

fatal: unable to create thread: Resource temporarily unavailable

... sugiere que se haya quedado sin memoria en el servidor, lo que puede suceder si tiene:

1. Un repositorio con muchos archivos de gran tamaño, lo que puede hacer que el reenvasado requiera mucha memoria.
2. Memoria virtual limitada, ya sea en general o solo por esa cuenta debido a la configuración de ulimit

Una sugerencia here es limitar la cantidad de memoria que puede llevar el embalaje iniciando sesión en el sistema remoto (ya que el usuario con el que se ejecuta git) y haciendo:

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

Answer 3

Actualización: esta respuesta fue una sugerencia de edición de la respuesta de Mark Longair, que ahora ha actualizado su respuesta con el nombre correcto.

De hecho, pack.SizeLimit es incorrecto, es pack.packSizeLimit .

Cuando agregué esta opción, funcionó para mí :)

Tuve que configurarlo tanto en el repositorio local como en el remoto.