À quelle fréquence devez-vous utiliser git-gc?


233

À quelle fréquence devez-vous utiliser git-gc?

La page de manuel dit simplement:

Les utilisateurs sont encouragés à exécuter cette tâche régulièrement dans chaque référentiel pour maintenir une bonne utilisation de l'espace disque et de bonnes performances de fonctionnement.

Existe-t-il des commandes pour obtenir le nombre d'objets pour savoir s'il est temps de passer au GC?


Des tâches comme celles-ci sont des candidats privilégiés pour cron (si vous utilisez linux) minhajuddin.com/2011/12/09/…
Khaja Minhajuddin

1
Remarque: le réglage gc.autodetach(Git 2.0 Q2 2014) peut aider à fonctionner git gc --autosans bloquer l'utilisateur. voir ma réponse ci-dessous .
VonC

Réponses:


204

Cela dépend principalement de la quantité d'utilisation du référentiel. Avec un utilisateur qui s'enregistre une fois par jour et une opération de branchement / fusion / etc une fois par semaine, vous n'avez probablement pas besoin de l'exécuter plus d'une fois par an.

Avec plusieurs dizaines de développeurs travaillant sur plusieurs dizaines de projets, chacun s'enregistrant 2 à 3 fois par jour, vous voudrez peut-être l'exécuter tous les soirs.

Cependant, cela ne fera pas de mal de l'exécuter plus fréquemment que nécessaire.

Ce que je ferais, c'est l'exécuter maintenant, puis dans une semaine, prendre une mesure de l'utilisation du disque, l'exécuter à nouveau et mesurer à nouveau l'utilisation du disque. S'il diminue de 5%, exécutez-le une fois par semaine. S'il baisse davantage, exécutez-le plus fréquemment. S'il baisse moins, exécutez-le moins fréquemment.


17
Le manuel dit "Certaines commandes git exécutent git gc --auto après avoir effectué des opérations qui pourraient créer de nombreux objets en vrac." Quelqu'un sait-il quelles commandes l'exécutent réellement?
Joshua Dance

2
Un grand rebase de git est un exemple évident, car de nombreux commits sont réécrits dans une nouvelle histoire - laissant beaucoup de vieux commits dans votre repo qui font partie de la branche actuelle
mafrosis

20
"Cela ne fera pas de mal de l'exécuter plus souvent que nécessaire" ... Je ne suis pas entièrement d'accord. Comme le souligne Aristote, les validations pendantes peuvent constituer un bon mécanisme de sauvegarde.
Jason Baker

105

Notez que l'inconvénient de la collecte des déchets de votre référentiel est que les déchets sont collectés. Comme nous le savons tous en tant qu'utilisateurs d'ordinateurs, les fichiers que nous considérons actuellement comme des déchets pourraient s'avérer très précieux trois jours à l'avenir. Le fait que git garde la plupart de ses débris a sauvé mon bacon plusieurs fois - en parcourant tous les commits pendantes, j'ai récupéré beaucoup de travail que j'avais accidentellement mis en conserve.

Alors ne soyez pas trop un monstre soigné dans vos clones privés. Il n'y en a guère besoin.

OTOH, la valeur de la récupérabilité des données est discutable pour les repos utilisés principalement comme télécommandes, par exemple. l'endroit où tous les développeurs poussent et / ou se retirent. Là, il pourrait être judicieux de lancer fréquemment un cycle GC et un reconditionnement.


38
FWIW tous les objets en vrac ne sont pas récupérés, seuls ceux de plus de 2 semaines par défaut (cf. git gc --help, en particulier l' --pruneoption). Il est également fait mention de gc.reflogExpire, ce qui m'amène à croire que tout engagement que vous avez visité au cours des 90 derniers jours ne sera pas collecté. (Ma version git: v1.7.6)
RobM

30

Les versions récentes de git exécutent automatiquement gc lorsque cela est nécessaire, vous ne devriez donc rien avoir à faire. Voir la section Options de man git-gc (1) : "Certaines commandes git exécutent git gc --auto après avoir effectué des opérations qui pourraient créer de nombreux objets lâches."


13
Je viens de l'exécuter pour la première fois sur un référentiel vieux de plusieurs années, et mon .git est passé de 16M à 2,9M, soit une réduction de 82%. Il semble donc toujours utile d'exécuter manuellement la commande.
Darshan Rivka Whittle du

@DarshanRivkaWhittle avez-vous mis à jour git au cours de ces dernières années?
std''OrgnlDave

1
@ std''OrgnlDave Oui, je faisais toujours tourner la version actuelle sur Arch. Je viens de le relancer, peut-être pour la première fois depuis mon dernier commentaire (grâce à votre commentaire me le rappelant), et mon .git est passé de 81M à 13M. Je ne dois exécuter aucune des commandes qui s'exécutent gc --auto, je suppose.
Darshan Rivka Whittle

18

Si vous utilisez Git-Gui , il vous indique quand vous devez vous inquiéter:

This repository currently has approximately 1500 loose objects.

La commande suivante apportera un nombre similaire:

$ git count-objects

Sauf que, depuis sa source , git-gui fera le calcul lui-même, comptant réellement quelque chose dans le .git/objectsdossier et apportant probablement une approximation (je ne sais tclpas lire correctement cela!).

En tout cas, il semble donner l'avertissement sur la base d'un nombre arbitraire d' environ 300 objets en vrac.


En effet, il avertit, mais en le laissant exécuter gc, la plupart du temps gc ne fera rien. Donc, s'appuyer sur git gui pour le faire, c'est attendre plus de 6000 objets lâches avec toujours avoir à cliquer sur exécuter gc et attendre une minute ou annuler: / Quelqu'un devrait probablement réparer git gui de manière à ce qu'il vérifie max loose nombre d'objets et pas la peine d'afficher la boîte de dialogue jusqu'à ce que le nombre atteigne la limite.
mlatu

Oui @mlatu, je suis d'accord. Quand j'ai écrit cela, je voulais juste attirer l'attention sur cela. Les deux Git-Guiet count-objectsne sont pas exactement de bonnes réponses à la question ici ... Mais ils devraient l'être!
cregox

Je ne voulais pas dire que c'était une mauvaise réponse, je voulais juste souligner que la plupart du temps, git gui ne fait rien. mais je suppose que git gc ne fait pas grand-chose non plus, sauf quand il y en a assez ou que vous avez utilisé le commutateur agressif.
mlatu

7

Déposez-le dans un travail cron qui s'exécute tous les soirs (après-midi?) Lorsque vous dormez.


7

J'utilise git gc après avoir effectué une grosse commande, et j'ai beaucoup de nouveaux objets. cela peut économiser de l'espace. Par exemple, si vous extrayez un gros projet SVN à l'aide de git-svn et effectuez un git gc, vous économisez généralement beaucoup d'espace


Est-ce toujours vrai? Même en '08, l'espace disque dur était bon marché, l'utiliser comme justification pour fonctionner semble inutile
Thymine

7

Vous pouvez le faire sans aucune interruption, avec le nouveau paramètre (Git 2.0 Q2 2014) gc.autodetach.

Voir commit 4c4ac4d et commit 9f673f9 ( Nguyễn Thái Ngọc Duy, alias pclouds ):

gc --autoprend du temps et peut bloquer temporairement l'utilisateur (mais pas moins gênant).
Faites-le fonctionner en arrière-plan sur les systèmes qui le prennent en charge.
La seule chose perdue avec l'exécution en arrière-plan est les impressions. Mais ce gc outputn'est pas vraiment intéressant.
Vous pouvez le conserver au premier plan en le modifiant gc.autodetach.


Depuis cette version 2.0, il y avait cependant un bug: git 2.7 (Q4 2015) s'assurera de ne pas perdre le message d'erreur .
Voir commit 329e6e8 (19 sept. 2015) de Nguyễn Thái Ngọc Duy ( pclouds) .
(Fusionné par Junio ​​C Hamano - gitster- en commit 076c827 , 15 oct.2015 )

gc: enregistrer le journal de démonized gc --autoet l'imprimer la prochaine fois

Bien que la validation 9f673f9 ( gc: option de configuration pour une exécution --autoen arrière-plan - 2014-02-08) aide à réduire certaines plaintes concernant le ' gc --auto' monopolisation du terminal, cela crée un autre ensemble de problèmes.

Le dernier de cet ensemble est, à la suite de la démonisation, stderrfermé et tous les avertissements sont perdus. Cet avertissement à la fin de "" cmd_gc()est particulièrement important car il indique à l'utilisateur comment éviter " gc --auto" de s'exécuter de façon répétée.
Parce que stderr est fermé, l'utilisateur ne sait pas, naturellement, il se plaint de ' gc --auto' gaspillage de CPU.

Daemonized gcenregistre maintenant stderrsur $GIT_DIR/gc.log.
Les opérations suivantes gc --autone seront pas exécutées et gc.logimprimées tant que l'utilisateur ne les supprimera pasgc.log
.


6

Cette citation est tirée de; Contrôle de version avec Git

Git exécute automatiquement la récupération de place :

• S'il y a trop d'objets en vrac dans le référentiel

• Lorsqu'un push vers un référentiel distant se produit

• Après quelques commandes qui pourraient introduire de nombreux objets en vrac

• Lorsque certaines commandes telles que git reflog expirent, le demander explicitement

Enfin, le garbage collection se produit lorsque vous le demandez explicitement à l'aide de la commande git gc. Mais quand cela devrait-il être? Il n'y a pas de réponse solide à cette question, mais il existe de bons conseils et de bonnes pratiques.

Vous devriez envisager d'exécuter git gc manuellement dans quelques situations:

• Si vous venez de terminer une branche de filtre git. Rappelez-vous que la branche de filtre réécrit de nombreuses validations, en introduit de nouvelles et laisse les anciennes sur une référence qui devrait être supprimée lorsque vous êtes satisfait des résultats. Tous ces objets morts (qui ne sont plus référencés puisque vous venez de supprimer la référence qui les pointe) doivent être supprimés via le garbage collection.

• Après quelques commandes qui pourraient introduire de nombreux objets lâches. Cela pourrait être un gros effort de rebase, par exemple.

Et d'un autre côté, quand devriez-vous vous méfier de la collecte des ordures?

• S'il existe des références orphelines que vous voudrez peut-être récupérer

• Dans le contexte de git rerere et vous n'avez pas besoin de sauvegarder les résolutions pour toujours

• Dans le contexte où seules les balises et les branches sont suffisantes pour que Git conserve un commit de façon permanente

• Dans le contexte des récupérations FETCH_HEAD (récupérations URL directes via git fetch) car elles sont immédiatement soumises à la récupération de place


2
J'ai des commits inaccessibles dans mon arbre (à la suite de git commit --amend). Cela peut être vérifié avec git log --reflog. J'ai poussé une branche vers le référentiel distant et vérifié à nouveau mon arborescence; les commits inaccessibles étaient toujours là. Apparemment, il git gcn'a pas été exécuté lorsque cette poussée s'est produite. …?
chharvey

4

J'utilise quand je fais un gros commit, surtout quand je supprime plus de fichiers du référentiel .. après, les commits sont plus rapides


1

Vous n'avez pas besoin de l'utiliser git gctrès souvent, car git gc(Garbage collection) est exécuté automatiquement sur plusieurs commandes fréquemment utilisées:

git pull
git merge
git rebase
git commit

Source: meilleures pratiques git gc et FAQ

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.