Cómo omitir emergente "Loose objeto" cuando se ejecuta 'git gui'

Question

Cuando corro 'git gui' me sale una ventana emergente que dice

 
This repository currently has approximately 1500 loose objects. 

Se sugiere entonces comprimir la base de datos. He hecho esto antes, y reduce los objetos sueltos a aproximadamente 250, pero eso no suprime la ventana emergente. Comprimir de nuevo no cambia la cantidad de objetos sueltos.

Nuestro flujo de trabajo actual requiere un uso significativo de 'rebase' ya que estamos en transición desde Perforce, y Perforce sigue siendo el SCM canónico. Una vez que Git sea el SCM canónico, haremos fusiones regulares, y el problema de los objetos sueltos debería mitigarse en gran medida.

Mientras tanto, me gustaría hacer desaparecer esta ventana emergente 'útil'.

Answer 1

Como nadie tenía todavía una respuesta, miré el código para ver cómo eliminar el código que muestra ese diálogo. Encontré el procedimiento hint_gc que lo hace y el lugar donde se llama. Al mismo tiempo, noté que a fines de 2011 se agregó a configuration option for disabling the dialog. Este cambio (parte de git-gui 0.16.0) se fusionó con la línea principal de Git en 2011-12-14.

tanto, si utiliza Git v1.7.9 o posterior, puede desactivar el diálogo de advertencia con el siguiente comando:

git config --global gui.gcwarning false 

Si está utilizando una versión anterior, entonces se puede editar y remover /lib/git-core/git-gui la línea after 1000 hint_gc, o edite /usr/share/git-gui/lib/database.tcl y elimine el cuerpo del procedimiento hint_gc. (Estas rutas de archivos están en Cygwin; en otros entornos, los archivos pueden estar en ubicaciones diferentes. Para Windows es c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl)

Answer 2

Cuando "Loose objeto" emergente sé que es el momento de ejecutar recolector de basura de git:

git gc 

Después de que el emergente desaparece.

Actualización: (debido a la sugerencia de T.E.D.)

extraje el siguiente proceso de git/share/git-gui/lib/database.tcl
Se puede modificar para satisfacer sus necesidades.

proc hint_gc {} { 
    set object_limit 8 
    if {[is_Windows]} { 
     set object_limit 1 
    } 

    set objects_current [llength [glob \ 
     -directory [gitdir objects 42] \ 
     -nocomplain \ 
     -tails \ 
     -- \ 
     *]] 

    if {$objects_current >= $object_limit} { 
     set objects_current [expr {$objects_current * 256}] 
     set object_limit [expr {$object_limit * 256}] 
     if {[ask_popup \ 
      [mc "This repository currently has approximately %i loose objects. 

To maintain optimal performance it is strongly recommended that you compress the database when more than %i loose objects exist. 

Compress the database now?" $objects_current $object_limit]] eq yes} { 
      do_gc 
     } 
    } 
} 

Answer 3

Hmmmm .... no veo un argumento de línea de comandos para que en el docs.

Supongo que siempre se puede extraer su fuente, sacar el código para el diálogo y reconstruir.

Answer 4

Actualización: git prune sería "resolver" el problema, ya que eliminará los objetos sueltos
(git gc llamadas git prune, pero sólo para los objetos sueltos de más de dos semanas, por defecto).
Sin embargo, como el OP Michael Donohue menciones en los comentarios:

me gusta el aspecto de la seguridad de mantener los objetos sueltos alrededor de dos semanas, debería querer volver atrás y mirar algunas versiones anteriores, por lo que don Realmente me gusta esta solución.
No estoy teniendo ningún problema con el tamaño o el rendimiento de git, es solo 'git gui' que insiste en pedirme que comprima la base de datos, incluso cuando la compresión de la base de datos no tendría ningún efecto.

---

Respuesta original:

El problema de la "git gc" no eliminar todos objetos sueltos se ha informado antes (a finales de 2008, ""git gc" doesn't seem to remove loose objects any more"

git gc sólo elimina suelta objetos de más de dos semanas, si realmente desea eliminarlos ahora, ejecute git prune.
Pero haga Asegúrese de que ningún otro proceso de git pueda estar activo cuando lo ejecute, o podría dar el paso en algo.

"git gc" desempaquetar objetos que se han vuelto inalcanzables y que estaban actualmente en paquetes.
Como resultado, la cantidad de espacio de disco utilizado por un repositorio de git puede ir hasta dramáticamente después de una operación "git gc", que podría ser sorprendente para alguien que está ejecutando casi en su sistema de archivos, elimina un número de las ramas de un repositorio de seguimiento, y luego hace un "git gc" puede obtener una sorpresa muy desagradable.

[ Ejemplo: ] Las ramas antiguas se reservan mediante una etiqueta como next-20081204.
Si actualiza su copia local del repositorio linux-next todos los días, acumulará una gran cantidad de estas antiguas etiquetas de ramificación.
Si luego elimina una serie completa de ellos y ejecuta git-gc, la operación llevará bastante tiempo, y la cantidad de bloques e inodos utilizados crecerá significativamente.

Desaparecerán después de un "git prune", pero cuando realizo esta operación de limpieza, a menudo he deseado una opción --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository para "git gc".

Entonces, en su caso, ¿sería útil un "git prune"?

(posiblemente con el uso de "ahora" en la variable de configuración gc.pruneexpire, necesaria para que ocurra el comportamiento anterior).

---

También tienen (desde el mismo hilo):

repack -a -d -l 

Aviso la minúscula 'a'.

git-gc llamadas reempaquetar con mayúscula 'A', que es lo que hace que los objetos inalcanzables para ser desempaquetados. Poco 'a', es para personas que saben lo que están haciendo, y quieren que Git simplemente arroje objetos inalcanzables.