tag - git remote

¿Cómo puedo activar la recolección de basura en un repositorio remoto de Git?

Question

Como sabemos, podemos ejecutar git gc periódicamente para empaquetar objetos bajo .git/objects .

En el caso de un repositorio de Git central remoto (desnudo o no), sin embargo, después de muchas myproj.git/objects , hay muchos archivos bajo myproj.git/objects ; Cada confirmación parece crear un nuevo archivo allí.

¿Cómo puedo empacar tantos archivos? (Me refiero a los que están en el repositorio central remoto remoto, no en el repositorio de clones locales).

Answer 1

después de muchos empujones, hay muchos archivos bajo myproj.git/objects

No habrá tanto con git 2.11+ (Q4 2016) y un gancho de pre-recepción.
En ese escenario, no tendrás que activar un git gc en absoluto .

Consulte commit 62fe0eb , commit e34c2e0 , commit 722ff7f , commit 2564d99 , commit 526f108 (03 Oct 2016) por Jeff King ( peff ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 25ab004 , 17 oct 2016)}

receive-pack : objetos en cuarentena hasta que se acepte la recepción previa

Para que el extremo receptor de "git push" inspeccione el historial recibido y decida rechazar el empuje, los objetos enviados desde el extremo de envío deben estar disponibles para el gancho y el mecanismo para la verificación de conectividad, y esto se hizo tradicionalmente almacenando los objetos en el repositorio de recepción y dejando que " git gc " caduque.

En su lugar, almacene los objetos recién recibidos en un área temporal, y haga que estén disponibles reutilizándoles el mecanismo de almacenamiento de objetos alternativos solo mientras decidimos si aceptamos la verificación, y una vez que decidimos, migrarlos al repositorio o eliminarlos de inmediato .

Esa área temporal se establecerá con la nueva variable de entorno GIT_QUARANTINE_ENVIRONMENT .

De esa manera, si un gancho de pre-receive rechaza un empuje (grande), esos objetos grandes no permanecerán por 90 días esperando que git gc limpie.

Answer 2

El repositorio remoto debe configurarse para ejecutar gc según sea necesario después de realizar una confirmación. Consulte la documentación de gc.auto en las páginas de manual de git-gc y git-config.

Sin embargo, un repositorio remoto no debería necesitar toda esa recolección de basura, ya que rara vez tendrá confirmaciones colgantes (inalcanzables). Por lo general, esto se debe a cosas como la eliminación de sucursales y la reorganización de la base de datos, que generalmente ocurren solo en repositorios locales.

Así que gc es más necesario para el reenvasado, que es para ahorrar espacio de almacenamiento en lugar de eliminar la basura real. La variable gc.auto es suficiente para cuidar esto.

Answer 3

Si bien debería tener algún proceso que se encargue de esto periódicamente, de forma automática, no es un problema ejecutar

git gc

en un repositorio desnudo

git@domU:/pix/git/repositories/abd.git$ ls -l

total 28
drwxrwxr-x   2 git git    6 2010-06-06 02:44 branches
-rw-rw-r--   1 git git   66 2010-06-06 02:44 config
-rw-r--r--   1 git git   23 2011-03-15 18:19 description
-rw-rw-r--   1 git git   23 2010-06-06 02:44 HEAD
drwxrwxr-x   2 git git 4096 2010-06-06 02:44 hooks
drwxrwxr-x   2 git git   20 2010-06-06 02:44 info
drwxrwxr-x 260 git git 8192 2010-09-01 00:26 objects
drwxrwxr-x   4 git git   29 2010-06-06 02:44 refs

$ git gc
Counting objects: 3833, done.
Compressing objects:  31% (1085/3500)...

Answer 4

Esta pregunta debería arrojar algo de luz sobre la frecuencia con la que debe ejecutar la recolección de basura.

La opción más fácil sería usar una tarea programada en Windows o un trabajo cron en Unix para ejecutar git gc periódicamente. De esta manera ni siquiera necesitas pensar en ello.