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

123

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».

Michael Donohue
la source
1
Cette boîte de dialogue est un excellent exemple d'une «fonctionnalité» dont beaucoup de gens souhaiteraient qu'elle n'existe pas. Ce n'est pas seulement ennuyeux, cela peut effacer les commits importants qui se sont détachés après une réinitialisation matérielle.
adelriosantiago

Réponses:

169

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)

Esko Luontola
la source
3
Pouvons-nous augmenter after 1000 hint_gcpour que l'avertissement se produise après 10000des objets en vrac?
sashoalm
@sashoalm Je suis d'accord. C'est là pour une raison.
HankCa
Je me demande quelles sont exactement les bonnes raisons, ce dialogue est une telle douleur, sans bonnes raisons clairement expliquées, je suis certainement très tenté de simplement frapper dans la commande ci-dessus.
Josh Mc
2
@sashoalm: C'est peut-être ce que vous voulez dire, mais le "1000" de after 1000fait référence au nombre de millisecondes à attendre jusqu'à ce que la boîte de dialogue s'affiche. En l'augmentant à "10000", la boîte de dialogue apparaîtra toujours, mais il lui faudra 10 secondes pour le faire à la place.
fuglede
1
Cependant, comme mentionné dans la réponse de @ NickDandoulakis, database.tclcontient la définition de la limite et peut être augmentée pour rendre le dialogue moins fréquent.
fuglede
50

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.

VonC
la source
1
'git prune' résoudrait probablement mon problème immédiat - je l'essayerai plus tard aujourd'hui. Cependant, 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.
Michael Donohue
commentaire très utile. Ce message ennuyeux "objet lâche" devenait vraiment ennuyeux. D'où vient ce décompte de toute façon? La sortie de git-fsck, peut-être?
David Dombrowsky
merci - j'avais aussi des objets en vrac que git gc ne supprimait pas - git prune était la réponse.
shedd
J'ai fait un élagage git en dehors de tout référentiel et cela a effacé certains objets. Ensuite, je suis allé dans le dépôt des problèmes et j'ai fait un élagage git et tous les problèmes ont disparu.
Nicholas Orlowski
"git prune" résout le problème qu'OP (et moi) avions: "Je l'ai déjà fait, et cela réduit les objets lâches à environ 250, mais cela ne supprime pas le popup."
Eike
32

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
        }
    }
}
Nick Dandoulakis
la source
1
Le fait de cliquer sur OK dans la boîte de dialogue ne fait-il pas exactement cela? Si gc ne se débarrassait pas de tous les objets en vrac, il obtiendrait toujours la boîte de dialogue.
TED
J'ai cliqué sur 'OK' et j'ai exécuté 'git gc' à partir de la ligne de commande - ils me ramènent tous les deux à 250, mais le faire à nouveau ne fait aucun progrès.
Michael Donohue
3
Je sais que c'est bizarre mais nettoyer la base de l'interface graphique laisse parfois des objets en vrac. Je ferme l'interface graphique, lance git-gc, puis toutes les ordures ont disparu.
Nick Dandoulakis
3
Changer le tcl le corrige - je viens d'augmenter la limite de Windows à 10 * 250. Merci!
Michael Donohue
pour moi, courir à git gcpartir de la ligne de commande a résolu le problème ... le simple fait de cliquer okdans git gui n'a pas fait l'affaire ...
Raphael
3

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.

TED
la source