¿Con qué frecuencia debe usar git-gc?

¿Con qué frecuencia debe usar git-gc?

La página del manual simplemente dice:

Se alienta a los usuarios a ejecutar esta tarea de forma regular dentro de cada repositorio para mantener una buena utilización del espacio en disco y un buen rendimiento operativo.

¿Hay algunos comandos para obtener algunos recuentos de objetos para averiguar si es hora de gc?

Depende principalmente de cuánto se use el repositorio. Con un usuario que se registra una vez al día y una operación de sucursal / fusión / etc. una vez a la semana, probablemente no necesite ejecutarlo más de una vez al año.

Con varias docenas de desarrolladores trabajando en varias docenas de proyectos cada uno ingresando 2-3 veces al día, es posible que desee ejecutarlo todas las noches.

Sin embargo, no hará daño ejecutarlo con más frecuencia de la necesaria.

Lo que haría es ejecutarlo ahora, luego dentro de una semana tomar una medida de la utilización del disco, ejecutarlo nuevamente y medir la utilización del disco nuevamente. Si cae un 5% de tamaño, ejecútelo una vez por semana. Si cae más, ejecútelo con más frecuencia. Si cae menos, ejecútelo con menos frecuencia.

Tenga en cuenta que la desventaja de recolectar basura en su repositorio es que, bueno, la basura se recolecta. Como todos sabemos como usuarios de computadoras, los archivos que consideramos basura en este momento podrían resultar muy valiosos tres días en el futuro. El hecho de que git mantenga la mayor parte de sus escombros ha salvado mi tocino varias veces: al examinar todas las confirmaciones colgantes, he recuperado mucho trabajo que accidentalmente había enlatado.

Así que no seas demasiado fanático de tus clones privados. Hay poca necesidad de ello.

OTOH, el valor de la capacidad de recuperación de datos es cuestionable para los repositorios utilizados principalmente como controles remotos, por ejemplo. el lugar donde todos los desarrolladores empujan y / o sacan. Allí, puede ser sensato iniciar una ejecución de GC y un reempaque con frecuencia.

Las versiones recientes de git ejecutan gc automáticamente cuando es necesario, por lo que no debería tener que hacer nada. Consulte la sección Opciones de man git-gc (1) : "Algunos comandos de git ejecutan git gc --auto después de realizar operaciones que podrían crear muchos objetos sueltos".

Si usa Git-Gui , le indica cuándo debe preocuparse:

This repository currently has approximately 1500 loose objects.

El siguiente comando traerá un número similar:

$ git count-objects

Excepto que, desde su origen , git-gui hará los cálculos por sí mismo, en realidad contará algo en la .git/objectscarpeta y probablemente traiga una aproximación (¡no sé tclleer eso correctamente!).

En cualquier caso, parece dar la advertencia basada en un número arbitrario de alrededor de 300 objetos sueltos.

Déjalo en un trabajo cron que se ejecuta todas las noches (¿por la tarde?) Cuando duermes.

Uso git gc después de hacer un pago grande y tengo muchos objetos nuevos. Puede ahorrar espacio. Por ejemplo, si realiza un pago de un gran proyecto SVN con git-svn y realiza un git gc, generalmente ahorra mucho espacio

Puede hacerlo sin interrupción, con la nueva configuración (Git 2.0 Q2 2014) gc.autodetach.

Ver commit 4c4ac4d y commit 9f673f9 ( Nguyễn Thái Ngọc Duy, también conocido como pclouds ):

gc --autolleva tiempo y puede bloquear al usuario temporalmente (pero no menos molesto).
Haz que se ejecute en segundo plano en sistemas que lo admitan.
Lo único que se pierde al ejecutar en segundo plano son las impresiones. Pero gc outputno es realmente interesante.
Puede mantenerlo en primer plano cambiando gc.autodetach.

Sin embargo, desde esa versión 2.0, hubo un error: git 2.7 (cuarto trimestre de 2015) se asegurará de no perder el mensaje de error .
Ver commit 329e6e8 (19 de septiembre de 2015) por Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 076c827 , 15 oct 2015)}

gc: guardar el registro de daemonized gc --autoe imprimirlo la próxima vez

Si bien commit 9f673f9 ( gc: opción de configuración para ejecutarse --autoen segundo plano - 2014-02-08) ayuda a reducir algunas quejas sobre ' gc --auto' acaparar el terminal, crea otro conjunto de problemas.

Lo último en este conjunto es, como resultado de la demonización, stderrse cierra y se pierden todas las advertencias. Esta advertencia al final de cmd_gc()es particularmente importante porque le dice al usuario cómo evitar " gc --auto" ejecutar repetidamente.
Debido a que stderr está cerrado, el usuario no lo sabe, naturalmente se quejan de gc --auto"malgastar CPU".

Daemonized gcahora salva stderra $GIT_DIR/gc.log.
Lo siguiente gc --autono se ejecutará e gc.logimprimirá hasta que el usuario lo eliminegc.log .

Esta cita está tomada de; Control de versiones con Git

Git ejecuta la recolección de basura automáticamente :

• Si hay demasiados objetos sueltos en el repositorio

• Cuando ocurre un envío a un repositorio remoto

• Después de algunos comandos que pueden introducir muchos objetos sueltos.

• Cuando algunos comandos como git reflog caducan, solicítelo explícitamente

Y finalmente, la recolección de basura ocurre cuando lo solicita explícitamente usando el comando git gc. ¿Pero cuándo debería ser eso? No hay una respuesta sólida a esta pregunta, pero hay algunos buenos consejos y mejores prácticas.

Debería considerar ejecutar git gc manualmente en algunas situaciones:

• Si acaba de completar una rama de filtro git. Recuerde que filter-branch reescribe muchas confirmaciones, introduce nuevas y deja las antiguas en una referencia que debe eliminarse cuando esté satisfecho con los resultados. Todos esos objetos muertos (a los que ya no se hace referencia ya que acaba de eliminar la referencia que los señala) deben eliminarse mediante la recolección de basura.

• Después de algunos comandos que pueden introducir muchos objetos sueltos. Esto podría ser un gran esfuerzo de rebase, por ejemplo.

Y por otro lado, ¿cuándo deberías tener cuidado con la recolección de basura?

• Si hay referencias huérfanas que quizás quieras recuperar

• En el contexto de git rerere y no es necesario guardar las resoluciones para siempre

• En el contexto de que solo las etiquetas y las ramas sean suficientes para hacer que Git retenga una confirmación de forma permanente

• En el contexto de las recuperaciones FETCH_HEAD (recuperaciones directas de URL a través de git fetch) porque están inmediatamente sujetas a la recolección de basura

Lo uso cuando hago un gran commit, sobre todo cuando elimino más archivos del repositorio ... después, los commits son más rápidos

No tiene que usarlo git gcmuy a menudo, porque git gc(Recolección de basura) se ejecuta automáticamente en varios comandos de uso frecuente:

git pull
git merge
git rebase
git commit

Fuente: mejores prácticas y preguntas frecuentes de git gc