¿Alguna vez necesito ejecutar git gc en un repository simple?

man git-gc no tiene una respuesta obvia, y tampoco he tenido suerte con Google (aunque podría haber estado utilizando términos de búsqueda erróneos).

Entiendo que ocasionalmente debe ejecutar git gc en un repository local para podar objects colgantes y comprimir el historial, entre otras cosas, pero ¿es un depósito descubierto compartido susceptible a estos mismos problemas?

Si es importante, nuestro flujo de trabajo consiste en múltiples desarrolladores que se desplazan desde un repository simple en una unidad de networking compartida. El repository "central" se creó con git init --bare --shanetworking .

Como Jefromi comentó sobre la respuesta de Dan , se debe llamar automáticamente a git gc durante el uso "normal" de un repository vacío.

Acabo de ejecutar git gc --aggressive en dos repositorys compartidos que se han usado activamente; uno con aproximadamente 38 commits las últimas 3-4 semanas, y el otro con aproximadamente 488 commits durante aproximadamente 3 meses. Nadie ha ejecutado manualmente git gc en ninguno de los repositorys.

Repositorio más pequeño

 $ git count-objects 333 objects, 595 kilobytes $ git count-objects -v count: 333 size: 595 in-pack: 0 packs: 0 size-pack: 0 prune-packable: 0 garbage: 0 $ git gc --aggressive Counting objects: 325, done. Delta compression using up to 4 threads. Compressing objects: 100% (323/323), done. Writing objects: 100% (325/325), done. Total 325 (delta 209), reused 0 (delta 0) Removing duplicate objects: 100% (256/256), done. $ git count-objects -v count: 8 size: 6 in-pack: 325 packs: 1 size-pack: 324 prune-packable: 0 garbage: 0 $ git count-objects 8 objects, 6 kilobytes 

Repositorio más grande

 $ git count-objects 4315 objects, 11483 kilobytes $ git count-objects -v count: 4315 size: 11483 in-pack: 9778 packs: 20 size-pack: 15726 prune-packable: 1395 garbage: 0 $ git gc --aggressive Counting objects: 8548, done. Delta compression using up to 4 threads. Compressing objects: 100% (8468/8468), done. Writing objects: 100% (8548/8548), done. Total 8548 (delta 7007), reused 0 (delta 0) Removing duplicate objects: 100% (256/256), done. $ git count-objects -v count: 0 size: 0 in-pack: 8548 packs: 1 size-pack: 8937 prune-packable: 0 garbage: 0 $ git count-objects 0 objects, 0 kilobytes 

Desearía haberlo pensado antes de gc estos dos repositorys, pero debería haber ejecutado git gc sin la opción --aggressive para ver la diferencia. Afortunadamente, tengo un repository activo de tamaño mediano que queda por probar (164 confirmaciones durante casi 2 meses).

 $ git count-objects -v count: 1279 size: 1574 in-pack: 2078 packs: 6 size-pack: 2080 prune-packable: 607 garbage: 0 $ git gc Counting objects: 1772, done. Delta compression using up to 4 threads. Compressing objects: 100% (1073/1073), done. Writing objects: 100% (1772/1772), done. Total 1772 (delta 1210), reused 1050 (delta 669) Removing duplicate objects: 100% (256/256), done. $ git count-objects -v count: 0 size: 0 in-pack: 1772 packs: 1 size-pack: 1092 prune-packable: 0 garbage: 0 $ git gc --aggressive Counting objects: 1772, done. Delta compression using up to 4 threads. Compressing objects: 100% (1742/1742), done. Writing objects: 100% (1772/1772), done. Total 1772 (delta 1249), reused 0 (delta 0) $ git count-objects -v count: 0 size: 0 in-pack: 1772 packs: 1 size-pack: 1058 prune-packable: 0 garbage: 0 

Ejecutar git gc claramente hizo una gran mella en count-objects , a pesar de que regularmente push y fetch de este repository. Pero al leer la página de manual para git config , noté que el límite de objects sueltos por defecto es 6700, que aparentemente aún no habíamos alcanzado.

Por lo tanto, parece que la conclusión es no , no es necesario ejecutar git gc manualmente en un repository simple; * pero con la configuration pnetworkingeterminada para gc.auto , puede pasar mucho time antes de que la recolección de basura ocurra automáticamente.


* En general , no debería necesitar ejecutar git gc . Pero a veces es posible que tenga poco espacio y ejecute git gc manualmente o establezca gc.auto en un valor inferior. Mi caso para la pregunta era simple curiosidad, sin embargo.

De la página man de git-gc :

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

Énfasis mío ¡Los depósitos desnudos también son repositorys!

Explicación adicional: una de las tareas domésticas que realiza git-gc es empaquetar y reempaquetar objects sueltos. Incluso si nunca tiene objects colgantes en su depósito desnudo, acumulará, con el time, muchos objects sueltos. Estos objects sueltos deben empacarse periódicamente para mayor eficiencia. De manera similar, si se acumula una gran cantidad de packages, periódicamente deben volverse a embalar en packages más grandes (less).

Algunas operaciones ejecutan git gc --auto automáticamente, por lo que nunca debería existir la necesidad de ejecutar git gc , git debería encargarse de esto por sí mismo.

Contrariamente a lo que dijo bwawok, en realidad hay (o podría haber) una diferencia entre su repository local y el descubierto: qué operaciones realiza con él. Por ejemplo, se pueden crear objects colgantes mediante el rebasado, pero es posible que nunca vuelva a establecer la base del repository desnudo, por lo que tal vez nunca tenga que eliminarlos (porque nunca los hay). Y por lo tanto, puede que no necesites usar git gc menudo. Pero, de nuevo, como dije, git debería encargarse de esto automáticamente.

El problema con git gc --auto es que puede estar bloqueando.

Pero con la nueva configuration (Git 2.0 Q2 2014) gc.autodetach , ahora puede hacerlo sin ninguna interrupción:

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

gc --auto lleva time y puede bloquear al usuario temporalmente (pero no less molestamente).
Haz que se ejecute en segundo plano en los sistemas que lo soportan.
Lo único que se pierde al ejecutarse en segundo plano son las impresiones. Pero la gc output no es realmente interesante.
Puede mantenerlo en primer plano cambiando gc.autodetach .


Nota: solo git 2.7 (Q4 2015) se asegurará de no perder el post de error .
Ver commit 329e6e8 (19 Sep 2015) por Nguyễn Thái Ngọc Duy ( pclouds ) .
(Fusionado por Junio ​​C Hamano – gitster – in commit 076c827 , 15 oct 2015)

gc : guarde el logging de daemonized gc --auto e imprímalo la próxima vez

Mientras commit 9f673f9 (opción gc : config para ejecutar --auto in background – 2014-02-08) ayuda a networkingucir algunas quejas sobre ' gc --auto ' acaparando el terminal, crea otro set de problemas.

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

Daemonized gc ahora guarda stderr en $GIT_DIR/gc.log .
Después de gc --auto no se ejecutará y se imprimirá gc.log hasta que el usuario elimine gc.log .

No sé 100% sobre la lógica de gc … pero para razonar esto:

git gc eliminó la basura adicional de la historia, comprime el historial adicional, etc. No hace nada con sus copys locales de files.

La única diferencia entre un repository normal y un repository es si tiene copys locales de los files.

Por lo tanto, creo que es lógico que SÍ, debe ejecutar git gc en un repository desnudo.

Nunca lo he ejecutado personalmente, pero mi repository es bastante pequeño y todavía es rápido.