Git pull fatal: Sin memory, malloc falló

Tengo un repo en https://bitbucket.org/

Hace unos días, por error, se empujó una gran cantidad de files de image en el repository. luego los files fueron eliminados a través de otro push. después de eso, el repository funcionó bien, pero hoy, cuando trato de sacarlo del repository:

$ git pull Password for 'https://[email protected]': warning: no common commits remote: Counting objects: 4635, done. remote: Compressing objects: 100% (1710/1710), done. fatal: Out of memory, malloc failed (tried to allocate 4266852665 bytes) fatal: index-pack failed 

He intentado:
1) git config --global pack.windowMemory 1024m
2)

 $ git count-objects -v count: 9 size: 48 in-pack: 4504 packs: 1 size-pack: 106822 prune-packable: 0 garbage: 0 

No hubo suerte allí, no estoy seguro de qué acciones debo seguir …
El tamaño del repository debe ser de alnetworkingedor de 10-20m de código. ¿Qué acciones debo seguir?

ACTUALIZACIÓN 1
ejecuté estos commands:

 $ git filter-branch --index-filter 'git rm --cached --ignore-unmatch public/images/*' HEAD Rewrite a1c9fb8324a2d261aa745fc176ce2846d7a2bfd7 (288/288) WARNING: Ref 'refs/heads/master' is unchanged 

y

 $ git push --force --all Counting objects: 4513, done. Compressing objects: 100% (1614/1614), done. Writing objects: 100% (4513/4513), 104.20 MiB | 451 KiB/s, done. Total 4513 (delta 2678), reused 4500 (delta 2671) remote: bb/acl: ayermolenko is allowed. accepted payload. To https://[email protected]/repo.git + 203e824...ed003ce demo -> demo (forced update) + d59fd1b...a1c9fb8 master -> master (forced update) 

Tire entonces funciona bien:

 $ git pull Already up-to-date. 

Pero cuando trato de clonar el repos, recibo

 ~/www/clone$ git clone [email protected]:repo.git Cloning into 'clone'... remote: Counting objects: 5319, done. remote: Compressing objects: 100% (1971/1971), done. fatal: Out of memory, malloc failed (tried to allocate 4266852665 bytes) fatal: index-pack failed 

ACTUALIZACIÓN 2
Lamentablemente, no encontré todos los files grandes. algunos todavía quedan. Entonces pedí soporte para matar todos los loggings del repository

ACTUALIZACIÓN 3
Al final tuve que matar al viejo y crear un nuevo repository.

Si usted es el único que usa este repository, puede seguir la opción git filter-branch descrita en " Cómo purgar un file enorme del historial de commits en Git? "

La opción más simple es clonar el repository a un compromiso anterior y forzarlo, como se describe en " git-filter-branch para eliminar un file grande ".

Cualquiera de los dos obligaría a cualquier queueborador a restablecer su propio repository local al nuevo estado que está publicando. De nuevo, si usted es el único queueborador, no es un problema.

En mi caso, fue algo tan simple como tratar de sacar un gran repository en una caja de memory RAM de 1GB sin intercambio.

Seguí este tutorial https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04 para crear un espacio de intercambio en el server y funcionó.

Su forma "más rápida":

 sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile 

Puede hacer permanentes estos cambios agregando a / etc / fstab:

 /swapfile none swap sw 0 0 

Recomiendan agregar a /etc/sysctl.conf:

 vm.swappiness=10 vm.vfs_cache_pressure = 50 

Incluso si los files de image grande se han eliminado después de haber sido empujados, permanecen en el historial de git .

Sugeriría que los eliminen por la fuerza del historial de git (creo que es posible, pero implica un procedimiento delicado que no sé).

Alternativamente, extraiga el repository antes de los files añadidos erróneamente, aplique parches al repository para crear los pequeños parches relevantes, clonelo y use eso (quizás con un volcado / restauración) como su maestro git.

No conozco bien los detalles, pero lo leí, podría ser posible

Hace poco encontré este problema con uno de mis repositorys. Error similar, insinuando un file grande escondido en el repository en alguna parte.

 Cloning into 'test_framework'... remote: Counting objects: 11889, done. remote: Compressing objects: 100% (5991/5991), done. Receiving objects: 66% (7847/11889), 3.22 MiB | 43 KiB/sremote: fatal: Out of memory, malloc failed (tried to allocate 893191377 bytes) remote: aborting due to possible repository corruption on the remote side. fatal: early EOFs: 66% (7933/11889), 3.24 MiB fatal: index-pack failed 

Para evitar esto, creé temporalmente una unidad de intercambio grande (en exceso de los 893191377 bytes que el server estaba pidiendo) siguiendo el Método 2 desde aquí: http://www.thegeekstuff.com/2010/08/how-to-add- swap-space /

Esto me permitió clonar con éxito y luego eliminar al culpable (alguien había ingresado un file dump de sql). Puedes usar:

 git filter-branch --tree-filter 'rm -rf dumpfile.sql' HEAD 

para eliminar el file del repository git.