gc Git usando excesivo de memoria, incapaz de completar

Question

actualización final y fijar: La solución en este caso resultó ser una combinación de dos cosas: el uso de Windows Git en lugar de Cygwin Git como Graham Borlandsuggested, y los ajustes de configuración de Git pack.threads = 1 y gc.aggressiveWindow = 150.

Tengo un gran repositorio local de Git, un git svn clone de un repositorio SVN con aproximadamente 40,000 confirmaciones. Estoy intentando ejecutar git gc sobre este repositorio, y llegar a ninguna parte:

$ git gc --auto 
Auto packing the repository for optimum performance. You may also 
run "git gc" manually. See "git help gc" for more information. 
Counting objects: 25966, done. 
Compressing objects: 100% (25249/25249), done. 
fatal: Out of memory, malloc failed (tried to allocate 426523986 bytes) 
error: failed to run repack 

estoy corriendo Git 1.7.5.1 dentro de Cygwin en una máquina Win7 de doble núcleo de 64 bits con 4 GB de RAM. El directorio .git actualmente tiene un poco más de 6.1GB.

He intentado ejecutar git gc --aggressive, para ver si el sistema más completo puede arreglarlo, pero no tuve suerte: recibí un mensaje similar al anterior, con el mismo tamaño intentado malloc, pero un conteo de objetos considerablemente más alto (508,485 contados, 493,506 comprimidos).

También he intentado -como lo sugieren los giros surtidos de Google a la parte [pack] de mi archivo .gitconfig; el ser más completo desde another StackOverflow question. Mi .gitconfig ahora tiene las siguientes líneas relevantes, pero el establecimiento de estos parece haber hecho ninguna diferencia:

[pack] 
     windowMemory = 16m 
     threads = 1 
     window = 1 
     depth = 1 
     deltaCacheSize = 1 

¿Alguna sugerencia sobre cómo puedo conseguir git a gc mi repositorio?

Editar: Mark Longairsuggested algunos más .gitconfig cambios en los archivos. Lo que hice, nuevas líneas a continuación. Pero los cambios no hicieron diferencia alguna.

[core] 
     packedGitWindowSize = 1m 
     packedGitLimit = 256m 
[pack] 
     packSizeLimit = 128m 

Editar 2: Michael Krelinsuggested aumentar el tamaño del archivo de intercambio/página (WinXP instrucciones here, y es similar para Windows 7). Intenté eso, pero no importó, y de hecho solo aumenté el tamaño máximo disponible, y parece que Windows nunca intentó aumentar el tamaño del archivo de página que estaba usando.

Ahora estoy viendo si esto fue causado por un límite de memoria dentro o impuesto a Cygwin. Para verificar "impuesta", intento ejecutar Cygwin con privilegios de administrador. Para marcar "dentro" (que parece más probable), estoy jugando con Cygwin's maximum memory settings.

Editar 3: Aunque prefiero usar Cygwin, resulta que el cliente de Windows Git se ocupa muy bien del problema de la memoria. Parece que voy a estar recurriendo a eso cada tanto cuando mi repositorio necesita una ordenada.

Answer 1

Puede tener más suerte ejecutando un cliente nativo de Windows como msysGit, en lugar de intentar hacerlo dentro de Cygwin.

Answer 2

¿Tal vez la adición temporal de un archivo de intercambio más grande que la vida y tomar unas cuantas tazas de café en otro lugar te ayuden?

Answer 3

Algunas otras opciones de configuración que puede que desee para tratar de restringir a menores que los valores por defecto son:

• pack.packSizeLimit
• core.packedGitWindowSize
• core.packedGitLimit

... todos los cuales son documentado en el git config documentation. En particular, vale la pena comprobar en cada caso qué unidades se entienden, con lo que he cometido errores en el pasado.

Answer 4

Tuve el mismo problema, intenté las soluciones mencionadas hasta ahora sin éxito. Pero mis problemas con git gc comenzaron después añadí grandes archivos de imagen de cesión temporal, por lo que crean archivos .gitattributes y apagados de compresión delta para los grandes archivos:

*.tga -delta 
*.psd -delta 

Funcionó.

Answer 5

La única cosa que ayude a evitar este error en Linux alojamiento compartido era añadir

[pack] 
    packSizeLimit = 64m 
    threads = 1 

a

.gitconfig 

Lo más importante fue "threads = 1"