¿Por qué git ejecuta "git gc –auto" en cada combinación?

Hoy, git comenzó a actuar de forma divertida (bueno, más divertida que de costumbre) al insistir en ejecutar git gc después de cada fusión, incluso si están espalda con espalda.

 C:\Projects\my-current-project>git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (16/16), done. remote: Total 16 (delta 11), reused 0 (delta 0) Unpacking objects: 100% (16/16), done. From git.company.com:git/ e992ce8..6376211 mybranch/next -> origin/mybranch/next Merge made by recursive. Auto packing the repository for optimum performance. You may also run "git gc" manually. See "git help gc" for more information. FIND: Parameter format not correct Counting objects: 252732, done. Delta compression using up to 2 threads. Compressing objects: 100% (59791/59791), done. Writing objects: 100% (252732/252732), done. Total 252732 (delta 190251), reused 252678 (delta 190222) Removing duplicate objects: 100% (256/256), done. .../stylesheets/style.css | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 

Esto es increíblemente perturbador, y me temo que eso significa que mi repository está corrupto de alguna manera (esta es la primera vez que lo he visto automáticamente gc ). ¿Son mis miedos infundados? Si mi repository está bien, ¿cómo puedo detener el auto-embalaje?

EDITAR

Creo que vi el problema.

Probablemente estés ejecutando Cygwin / git o MsysGit en Windows. Me di count de que debido a la

 FIND: Parameter format not correct 

post de error. El problema es que en algún lugar sus scripts de gancho (o git internamente ?!) están llamando a find, que no encuentra la utilidad de búsqueda UNIX (GNU) sino que encuentra el Windows (MSDOS … sic) FIND.EXE.

Debería poder arreglar la ruta amplia de su sistema. Si esa no es una opción, explícitamente especifique la variable de entorno PATH dentro de su script (o antes de invocarlos)


Vieja respuesta para información:

git gc --auto no siempre da como resultado ninguna acción; ¿Estás seguro de que esto lleva time cada vez, o acabas de notar que se está llamando?

Si se la llama cada vez, es posible que

  • compruebe los permissions del repository (¡asegúrese de que pueda escribirlo por completo!)
  • git fsck
  • git reenvasado
  • git bundle --create mybundle.git --all y git clone mybundle.git para ver si de alguna manera puedes 'sacudir' al culpable
  • ver si puede actualizar a una versión posterior
  • si todo lo demás falla, aplique o depure el binary git-gc

Opcionalmente, cuando haya agitado al culpable, tal vez pueda analizar qué es diferente entre su repository "limpio" y el actual.

De la página de manual de git-gc :

Con esta opción, git gc verifica si se requiere algún service de limpieza; si no, sale sin realizar ningún trabajo. Algunos commands de git ejecutan git gc –auto después de realizar operaciones que podrían crear muchos objects sueltos.

Se requiere limpieza si hay demasiados objects sueltos o demasiados packages en el repository. Si la cantidad de objects sueltos excede el valor de la variable de configuration gc.auto, todos los objects sueltos se combinan en un único package usando git repack -d -l. Establecer el valor de gc.auto en 0 desactiva el empaque automático de objects sueltos.

Si el número de packages excede el valor de gc.autopacklimit, los packages existentes (excepto los marcados con un file .keep) se consolidan en un solo package utilizando la opción -A de git repack. Establecer gc.autopacklimit a 0 desactiva la consolidación automática de packages.

Estoy agregando esta respuesta a pesar de que no responde el problema específico del cartel original porque cada vez que uno de mis reposiciones comienza a empaquetarse automáticamente después de cada fusión, he olvidado la solución, la busco de nuevo y encuentro esta pregunta primero.

Cuando uno de mis repos comienza "Embalaje automático del repository para un performance óptimo" después de cada combinación,

 git gc --prune=now 

lo arregla (Al estar en una Mac, no tengo el FIND: Parameter format not correct problema FIND: Parameter format not correct .) En este momento estoy usando git 2.4.1, pero esto me ha funcionado para varias versiones de 2. *.

Esta respuesta a Cómo eliminar blobs no referencedos de mi repository git sugiere que uno podría necesitar borrar el reflog de uno

 git reflog expire --expire-unreachable=now --all 

para que el command anterior sea máximamente efectivo, pero nunca tuve que hacer eso para arreglar el auto empaquetamiento después de cada fusión.

¿Qué versión de git estás usando? En cualquier caso, creo que el gc automático es extremadamente perturbador.

git config --global gc.auto 0

Su repository debe tener una gran cantidad de objects con los que los hashes comienzan con 17. Así que esto desencadena git gc –auto. El valor pnetworkingeterminado es al less 28 objects con el prefijo 17.