tipos - git ver archivos modificados

¿Alguna vez necesito ejecutar git gc en un repositorio desnudo?

Question

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, de vez en cuando, debe ejecutar git gc en un repositorio local para podar objetos 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 repositorio simple en una unidad de red compartida. El repositorio "central" se creó con git init --bare --shared .

Answer 1

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 repositorio local y el descubierto: qué operaciones hace con él. Por ejemplo, se pueden crear objetos colgantes mediante el rebasado, pero es posible que nunca vuelva a establecer la base del repositorio 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.

Answer 2

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

Acabo de ejecutar git gc --aggressive en dos repositorios 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 repositorios.

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 repositorios, pero debería haber ejecutado git gc sin la opción --aggressive para ver la diferencia. Afortunadamente, tengo un repositorio 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 repositorio. Pero al leer la página de manual para git config , noté que el límite de objetos 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 repositorio simple; ^* pero con la configuración predeterminada para gc.auto , puede pasar mucho tiempo 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.}

Answer 3

De la página man de git-gc :

Se recomienda a los usuarios 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.

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

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

Answer 4

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

Pero con la nueva configuración (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 tiempo y puede bloquear al usuario temporalmente (pero no menos 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 mensaje 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 registro 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 reducir algunas quejas sobre '' gc --auto '' acaparando el terminal, crea otro conjunto de problemas.

Lo último en este conjunto 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 .

Answer 5

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 copias locales de archivos.

La única diferencia entre un repositorio normal y un repositorio es si tiene copias locales de los archivos.

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

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