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

À 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?

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.

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.

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

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.

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

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

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 .

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

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

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