¿Se requiere git explict gc en git en el uso compartido de files?

Somos un equipo de desarrollo que tiene nuestro repository central en un file compartido de Windows.

Uno de nuestros desarrolladores erróneamente impulsó una gran cantidad de confirmaciones en una sucursal. Después de eso, eliminamos esa twig del repository central, pero obviamente eso realmente no elimina las confirmaciones.

Como se trata de un solo recurso compartido de files, no hay ningún process en el server de files que ejecute automáticamente git gc .

¿Necesitamos ejecutar git gc explícitamente en el repository central?

Tampoco hay ningún process para sus repositorys locales.
git gc no es ejecutado por un service en segundo plano. Es ejecutado automáticamente por el cliente después de ciertos commands como commit o push cuando se alcanza un determinado umbral de objects que deberían eliminarse.

Como dijo Daniel, el hecho de que el repository esté en un sistema de files compartido no es nada especial para Git: es lo mismo que si este repository estuviera ubicado en un sistema de files normal. Por lo tanto, no hay server sino solo un grupo de processs Git "del lado del cliente" que acceden al mismo repository.

Es decir, este caso no es realmente diferente del caso de un repository local "normal" que solo suele ser operado por un único desarrollador.

Como el manual de git-gc indica que Git realiza ciertas comprobaciones en el repository mediante la ejecución de git gc --auto que puede detectar que el GC es necesario y realizarlo.

Asi que…

  1. git gc --auto generará automáticamente mediante un process de Git ejecutado por uno de los desarrolladores que operan en ese repository. Esto sucederá solo.

    La operación precisa de Git que podría desencadenar esto no está explícitamente especificada en la documentation. Creo que esto se debe a que no tiene sentido codificar esto (este tipo de GC se supone que es rápido y transparente de todos modos).

  2. No veo ninguna razón por la que te abstengas de ejecutar git gc --aggressive a mano para reclamar el espacio libre.

    Sin embargo, debes tener en count que si tienes habilitado el reflog, probablemente querrás

    • Asegúrate de que el reflog se haya vaciado (a través de git reflog expire --all o de un método más detallado como borrar manualmente solo las inputs necesarias de él).
    • No hay otros refs persistentes (twigs o tags) apuntando a ese historial no deseado.

    También tenga en count que aunque Git debe serializar correctamente todos los accesos al repository y emplear operaciones de "crear y más; cambiar el nombre atómico" al manipular objects, le pediría a los desarrolladores que no accedan al repository mientras se realiza la recolección de elementos no utilizados.

PD. Puede encontrar este hilo interesante de leer, y en particular esta publicación a la que se refiere la discusión.

respuesta incorrecta lea los comentarios.

git gc elimina los objects inalcanzables que se han creado (con git add .) No creo que pueda eliminar un file comprometido.