El reposicionamiento del repositorio Git falla

Question

Tengo un repositorio git que reside en un servidor con memoria limitada. Cuando intento de clonar un repositorio existente desde el servidor me sale el siguiente error

hemi@ubuntu:$ git clone ssh://hemi@servername.dk/home/hemi/repos/articles 
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/ 
hemi@servername.dk's password: 
remote: Counting objects: 666, done. 
remote: warning: suboptimal pack - out of memory 
remote: fatal: Out of memory, malloc failed 
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: early EOF 
fatal: index-pack failed 
hemi@ubuntu:$ 

Para controlar este error he intentado volver a embalar el repositorio inicial (según this forum post). Pero en lugar de volver a empaquetar el repositorio, describe cómo usar el comando "git pack-objects".

hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m 
usage: git pack-objects [{ -q | --progress | --all-progress }] 
     [--all-progress-implied] 
     [--max-pack-size=N] [--local] [--incremental] 
     [--window=N] [--window-memory=N] [--depth=N] 
     [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] 
     [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] 
     [--reflog] [--stdout | base-name] [--include-tag] 
     [--keep-unreachable | --unpack-unreachable 
     [<ref-list | <object-list] 

Git 1.6.5.7 está instalado en el servidor.

Answer 1

Su solución tiene una copia de trabajo local y remota, pero causará problemas nuevamente cuando el repositorio remoto decida volver a empaquetarse. Afortunadamente, puede establecer opciones de configuración que reduzcan la cantidad de memoria necesaria para reempaquetar en ambos repositorios; básicamente, estos parámetros de línea de comandos que agregó a las opciones predeterminadas al reempaquetar. Por lo tanto, debe iniciar sesión en el control remoto, el cambio en el repositorio y hacer:

git config pack.windowMemory 10m 
git config pack.packSizeLimit 20m 

es posible que desee hacer lo mismo en su repositorio local. (Por cierto, supongo que, o bien su repositorio es muy grande o se trata de máquinas con poca memoria -. Estos valores parecen muy bajo para mí)

Por lo que vale la pena, al conseguir fracasos malloc volver a embalar muy grandes depósitos en el pasado, también he cambiado los valores de core.packedgitwindowsize, core.packedgitlimit, core.deltacachesize, pack.deltacachesize, pack.window y pack.threads pero suena como si usted no necesita ninguna opción más :)

Answer 2

Estoy usando git versión 1.7.0.4 y acepta este comando. Es posible que la versión 1.6 de git no acepte este comando.

Intenta crear un nuevo repositorio con algunas confirmaciones aleatorias. Luego vuelva a embalarlo con este comando.

Answer 3

He resuelto el problema utilizando los siguientes pasos.

1. repositorio dieron el ingreso a cabo desde el servidor a mi máquina local (utilizando una copia en bruto a través de ssh)
2. Embalados de nuevo el repositorio local
   git repack -a -d --window-memory 10m --max-pack-size 20m
3. Creado un repositorio vacío en el servidor
   git init --bare
4. Empujó el repositorio local al servidor
5. Comprobó que es posible clonar el repositorio del servidor

Answer 4

esto no responde a la pregunta, pero alguien podría encontrarlo: el reempaquetado también puede fallar en el servidor cuando pack-objects es terminado por algún tipo de asesino de memoria (Tal como la utilizada en Dreamhost):

$ git clone project-url project-folder 
Cloning into project-folder... 
remote: Counting objects: 6606, done. 
remote: Compressing objects: 100% (2903/2903), done. 
error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s 
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: early EOF 
fatal: index-pack failed 

En Dreamhost este parece ser causada por mmap.El código de reempaquetado usa mmap para asignar el contenido de algunos archivos a la memoria, y como el eliminador de memoria no es lo suficientemente inteligente, cuenta los archivos mmapped como memoria utilizada, lo que elimina el proceso de Git cuando intenta mmap un archivo grande.

La solución es compilar un binario personalizado de Git con soporte mmap apagado (configure NO_MMAP=1).

Answer 5

Sin acceso directo al repositorio y, por lo tanto, no pudiendo realizar un reempaquetado, realizar una clonación superficial y luego ir a buscar gradualmente mientras aumentaba la profundidad me ayudó.

git clone YOUR_REPO --depth=1 
git fetch --depth=10 
... 
git fetch --depth=100 
git fetch --unshallow //Downloads all history allowing to push from repo 

Espero que todavía pueda ayudar a alguien.

Answer 6

Tuve el mismo problema en ubuntu 14.10 con git 2.1.0 en un repositorio privado de github.com. (! Se sospecha enrutador Entreprise funciona en diferentes redes wifi, excepto en el lugar de trabajo)

* GnuTLS recv error (-54): Error in the pull function. 
* Closing connection 2jects: 31% (183/589) 
error: RPC failed; result=56, HTTP code = 200 
fatal: The remote end hung up unexpectedly 
fatal: protocol error: bad pack header 

Mi solución fue, a git clone usando ssh (I fijó claves ssh * antemano), así:

git clone https://github.com/USERNAME/REPOSITORYNAME.git

se convierte en:

git clone git@github.com: NOMBRE DE USUARIO/REPOSITORYNAME.git

*: (Generación de una clave SSH)

ssh-keygen -t rsa -C "your_email_address_registered_with_github@domain.com"

Luego inicie sesión en github, en la configuración, importe ssh keys, e impórtelo desde ~/.ssh/id_rsa.pub.