¿Qué significa "Empaquetado automático del repositorio para un rendimiento óptimo"?

Tengo un problema con mi repositorio de git. Durante los últimos días, cada vez que hago un envío al servidor, recibo este mensaje: "Empaquetado automático del repositorio para un rendimiento óptimo", y parece que no desaparece y devuelve el shell.

También intenté ir a una nueva rama y luego hacer un cambio de base en mi rama anterior y luego lo hice git gcpara eliminar los objetos de historial no utilizados y luego presioné, pero aún aparece este mensaje. Por favor, hágame saber qué está pasando con mi repositorio.

Versión corta: significa lo que dice, y si lo dejas terminar, todo estará bien.

Durante la mayoría de las operaciones que potencialmente pueden aumentar el número de objetos sueltos (desempaquetados) en el repositorio (incluidos los empujes), Git invoca git gc --auto. Si hay suficientes objetos sueltos (por defecto, al menos 6700), invocará git repack -d -lpara empacarlos. Si hay demasiados paquetes separados, también los volverá a empaquetar en uno.

Un paquete es un archivo único comprimido en delta, que contiene una gran cantidad de objetos. Es más eficiente almacenar objetos en paquetes, pero lleva tiempo empaquetar (comprimir) los objetos, por lo que Git inicialmente crea objetos sueltos, luego los empaca en lotes de vez en cuando, mediante la invocación automática de git gc --auto.

Si dejas que Git termine de reempacar, esto no volverá a suceder por un tiempo. De hecho, puede llevar un tiempo, especialmente si tiene muchos objetos binarios grandes, pero si se dispara, es una señal de que probablemente reducirá drásticamente la cantidad de espacio en disco que ocupa el repositorio. Si realmente no desea que suceda, puede cambiar el parámetro de configuración gc.auto. Si lo aumenta a algo mucho más grande que 6700, sucederá con menos frecuencia, pero tomará más tiempo cuando lo haga. Si lo disminuye, aún tendrá que hacer su reempaque actual, pero posteriormente sucederá con más frecuencia y terminará más rápidamente. Si lo configura en 0, deshabilitará el reempaque automático.

Consulte man git-gc(debajo --auto) y man git-config(debajo gc.auto) para obtener más información.

Si bien Jefroni tiene razón en que a veces el autoenvasado solo necesita tiempo para completarse, si el mensaje de autoenvasado persiste durante varios días como lo describe OP, hay una buena posibilidad de que la limpieza de git no tenga objetos colgantes, como se describe en esta pregunta .

Para ver si los objetos colgantes están activando mensajes continuos sobre el empaque automático, intente ejecutar git fsck. Si obtiene una larga lista de confirmaciones pendientes, puede limpiarlas con

git gc --prune=now

Por lo general, tengo que ejecutar esto en mi repositorio cada 2-3 meses cuando el mensaje de empaque automático no desaparece después de un solo tirón.

Para deshabilitar para un proyecto:

cd your_project_dir
git config gc.auto 0

Para deshabilitar globalmente:

git config --global gc.auto 0

Git ejecuta git-repack, que empaqueta muchos objetos (= archivos, confirmaciones y árboles) en un archivo de paquete. Git hace esto a veces, cuando una heurística dice que puede haber espacio ahorrado (un archivo de paquete contiene deltas de objetos comprimidos, mientras que cada archivo en el directorio objetos / contiene el contenido del archivo completo comprimido)

Con suerte, ese git gc --autopaso es ahora (git 2.0.1, 25 de junio de 2014) más eficiente.
Ver commit 62aad18 por Nguyễn Thái Ngọc Duy ( pclouds)

gc --auto: no bloquee las referencias en segundo plano

9f673f9 ( gc: opción de configuración para ejecutar --auto en segundo plano - 2014-02-08, Git 2.0.0) pone " gc --auto" en segundo plano para reducir el tiempo de espera del usuario.
Parte de la recolección de basura es empacar refs y podar reflogs. Estos requieren bloquear algunas referencias y pueden abortar otros procesos que intentan bloquear la misma referencia.

Si gc --autose dispara en medio de un script, los bloqueos de retención de gc en el fondo podrían fallar el script, lo que nunca podría suceder antes de 9f673f9 .

Siga ejecutándose pack-refsy " reflog --prune" en primer plano para detener las actualizaciones de referencia paralelas. Las operaciones de fondo restantes (reempaquetar, podar y volver a cortar) no deberían afectar los procesos de ejecución de git.

Y Git 2.22 (Q2 2019) optimiza aún másgit gc .