Comment ignorer la fenêtre contextuelle «Loose Object» lors de l'exécution de 'git gui'

Quand je lance 'git gui', j'obtiens une fenêtre contextuelle qui dit

Ce référentiel contient actuellement environ 1500 objets en vrac.

Il suggère ensuite de compresser la base de données. Je l'ai déjà fait et cela réduit les objets lâches à environ 250, mais cela ne supprime pas la fenêtre contextuelle. Une nouvelle compression ne modifie pas le nombre d'objets lâches.

Notre flux de travail actuel nécessite une utilisation significative du «rebase» alors que nous passons de Perforce, et Perforce est toujours le SCM canonique. Une fois que Git sera le SCM canonique, nous ferons des fusions régulières, et le problème des objets lâches devrait être considérablement atténué.

En attendant, j'aimerais vraiment faire disparaître cette fenêtre contextuelle «utile».

Puisque personne n'avait encore de réponse, j'ai regardé dans le code pour voir comment supprimer le code qui affiche cette boîte de dialogue. J'ai trouvé la hint_gcprocédure qui le fait et l'endroit où il est appelé. En même temps, j'ai remarqué qu'à la fin de 2011, une option de configuration avait été ajoutée pour désactiver la boîte de dialogue . Ce changement (qui fait partie de git-gui 0.16.0) a été fusionné avec la ligne principale de Git le 14/12/2011 .

Donc, si vous utilisez Git v1.7.9 ou plus récent, vous pouvez désactiver la boîte de dialogue d'avertissement avec la commande suivante:

git config --global gui.gcwarning false

Si vous utilisez une version plus ancienne, vous pouvez modifier /lib/git-core/git-guiet supprimer la after 1000 hint_gcligne, ou modifier /usr/share/git-gui/lib/database.tclet supprimer le corps de la hint_gcprocédure. (Ces chemins de fichiers se trouvent sur Cygwin - sur d'autres environnements, les fichiers peuvent se trouver à des emplacements différents. Pour Windows, c'est le cas c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl)

Mise à jour: git prune«résoudrait» le problème, en ce sens qu'il supprimera ces objets en vrac
( git gcappels git prune, mais uniquement pour les objets en vrac de plus de deux semaines, par défaut).
Cependant, comme le mentionne l' OP Michael Donohue dans les commentaires:

J'aime l'aspect sécurité de garder les objets en vrac pendant deux semaines, si je veux revenir en arrière et regarder quelques anciennes révisions, donc je n'aime pas vraiment cette solution.
Je n'ai aucun problème avec la taille ou les performances de git, c'est juste 'git gui' qui insiste pour me demander de compresser la base de données, même si la compression de la base de données n'aurait aucun effet.

Réponse originale:

Le problème de " git gc" ne pas supprimer tous les objets en vrac a déjà été signalé (fin 2008, " " git gc"ne semble plus supprimer les objets en vrac "

git gcne supprime que les objets lâches de plus de deux semaines, si vous voulez vraiment les supprimer maintenant, exécutez git prune.
Mais assurez-vous qu'aucun autre processus git ne peut être actif lorsque vous l'exécutez, ou il pourrait éventuellement marcher sur quelque chose.

" git gc" décompressera les objets devenus inaccessibles et qui se trouvaient actuellement dans des packs.
En conséquence, la quantité d'espace disque utilisée par un référentiel git peut en fait augmenter considérablement après une git gcopération " ", ce qui pourrait être surprenant pour quelqu'un qui est presque plein sur son système de fichiers, supprime un certain nombre de branches d'un référentiel de suivi , puis fait un " git gc" peut avoir une surprise très désagréable.

[Exemple: les ]anciennes branches sont réservées via une balise telle que next-20081204.
Si vous mettez à jour votre copie locale du linux-nextréférentiel chaque jour, vous accumulerez un grand nombre de ces anciennes balises de branche.
Si vous en supprimez ensuite toute une série et que vous l'exécutez git-gc, l'opération prendra un certain temps et le nombre de blocs et d'inodes utilisés augmentera considérablement.

Ils disparaîtront après un " git prune", mais quand je fais cette opération de ménage, j'ai souvent souhaité une --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repositoryoption pour "git gc".

Dans votre cas, est-ce qu'un " git prune" serait utile?

(éventuellement en utilisant "now" dans la gc.pruneexpirevariable de configuration, nécessaire pour que le comportement ci-dessus se produise).

Vous avez également (à partir du même fil):

repack -a -d -l

Notez le «a» minuscule.

git-gcappelle repack avec 'A' majuscule, ce qui provoque le décompactage des objets inaccessibles. Le petit 'a' est destiné aux personnes qui savent ce qu'elles font et qui veulent que git laisse simplement tomber les objets inaccessibles.

Lorsque la fenêtre contextuelle "Loose Object", je sais qu'il est temps d'exécuter le garbage collector de git:

git gc

Après cela, la fenêtre contextuelle disparaît.

Mise à jour: (en raison de la suggestion de TED)

j'ai extrait la routine ci-dessous de git/share/git-gui/lib/database.tcl
Vous pouvez la modifier pour répondre à vos besoins.

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
        }
    }
}

Hmmmm .... Je ne vois pas d'argument de ligne de commande pour cela dans la documentation .

Je suppose que vous pouvez toujours extraire sa source, retirer le code de la boîte de dialogue et reconstruire.