git - tag - Todo el equipo recibe mensajes de ''demasiados objetos sueltos'' inalcanzables

para que es git branch

Question

No hace mucho, hemos hecho el cambio de SVN a Git.

Hace unos días, me di cuenta de que todo nuestro equipo recibe esos mensajes cuando presionan:

$ git push
Counting objects: 32, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (32/32), 2.94 KiB | 0 bytes/s, done.
Total 32 (delta 14), reused 0 (delta 0)
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run ''git prune'' to remove them.

To [email protected]:root/xxx.git
   15c3bbb..69e6d8b  xxxx -> xxx

Pensé que venía de mi computadora por un tiempo, hasta que me doy cuenta de que todos tienen los mismos problemas.

No hace falta decir que no hay gc.log en mi carpeta .git, y el uso de ''git gc'' o ''git prune'' no tiene ningún efecto.

Así que mi pregunta es: ¿podría ser que el repositorio alojado en el servidor no esté limpio de alguna manera? Si es así, ¿cómo limpiarlo realmente?

Todas las soluciones que he encontrado hasta ahora se relacionan con las copias locales de los repositorios.

Además, usamos Gitlab para alojar nuestros repositorios.

EDITAR: Vale la pena decir que desde que publiqué esta pregunta también intenté "Limpieza del hogar" en el repositorio usando Gitlab pero sin resultados hasta el momento.

Gracias

Answer 1

A esto le sigue el problema 14357 (GitLab 8.6- o menos)

El arreglo manual fue:

• SSH en worker1
• cd en el directorio gitlab-org / gitlab-ce
• corrió rm gc.log , esto solo contenía la línea "advertencia: hay demasiados objetos sueltos inalcanzables; ejecute ''git prune'' para eliminarlos".
• corrió git prune y oró para que no rompiera las cosas (que afortunadamente no lo hizo)

Pero parece que, al iniciar GitLab 8.7, auto gc está deshabilitado .
Esto también se hace en el contexto del problema (aún abierto) 13524 :

Normalmente, después de una rebase, enmienda u otra acción que requiere un impulso de fuerza, podemos tener compromisos colgados.

Dichas confirmaciones "desreferenciadas" se están perdiendo debido a git gc que puede ejecutarse internamente o mediante el uso de las funciones de mantenimiento de GitLab.

Si sucede que hubo una discusión adjunta a un compromiso específico, no estará disponible después de que se haya recolectado la basura de la eliminación de referencias.

Los compromisos se están registrando en eventos de inserción y están disponibles a través de las notas del sistema agregadas para combinar la solicitud, y actualmente esto produce el error 500 en GitLab.

Actualización: ese problema se cerró un mes después (julio de 2016) con:

• MR 5062 : No haga recolecciones de basura que tengan registros de DB relacionados como comentarios

Se asegura de que se mantiene una confirmación cuando se ejecuta la recolección de basura Git.
Git GC eliminará las confirmaciones del repositorio que ya no están en ninguna rama o etiqueta, pero queremos mantener algunas de estas confirmaciones, por ejemplo, si tienen comentarios o compilaciones de CI.

• MR 4101 : Refactor: Convertir ref refs basados ​​en arreglos existentes al modelo DiffRefs