git-gc - Efface les fichiers non-nécessaires et optimiser le dépôt local

Exécute un certain nombre de tâches ménagères dans le dépôt actuel, comme la compression des révisions de fichiers (pour réduire l’espace disque et augmenter les performances), la suppression des objets inaccessibles qui peuvent avoir été créés par des invocations antérieures de git add, l’empaquetage des références, l’élagage des métadonnées reflog, rerere ou des arbres-de-travail périmés. Peut également mettre à jour des index auxiliaires tels que le commit-graph.

Quand les opérations courantes de porcelaine qui créent des objets sont exécutées, elles vérifieront si le dépôt a grandi de façon substantielle depuis la dernière maintenance, et si c’est le cas, elles lanceront automatiquement git gc. Voir gc.auto ci-dessous pour savoir comment désactiver ce comportement.

Exécuter git gc manuellement ne devrait être nécessaire que lors de l’ajout d’objets à un dépôt sans exécuter régulièrement de telles commandes de porcelaine, pour faire une optimisation ponctuelle du dépôt, ou par exemple pour nettoyer un import de masse sous-optimal. Voir la section "OPTIMISATION DU DÉPÔT" dans git-fast-import[1] pour plus de détails sur le cas de l’importation.

Quand l’option --aggressive est fournie, git-repack[1] sera invoqué avec l’option -f, qui à son tour passera --no-reuse-delta à git-pack-objects[1]. Cela jettera tous les deltas existants et les recalculera, au prix de passer beaucoup plus de temps sur le ré-empaquetage.

Les effets de ceci sont principalement persistants, par exemple lorsque des paquets et des objets libres sont fusionnés dans un autre paquet, les deltas existants dans ce paquet peuvent être réutilisés, mais il y a aussi plusieurs cas où nous pouvons choisir un delta sous-optimal d’un paquet plus récent à la place.

De plus, fournir --aggressive modifiera les options --depth et --window passées à git-repack[1]. Voir les paramètres gc.aggressiveDepth et gc.aggressiveWindow ci-dessous. En utilisant une taille de fenêtre plus grande, nous avons plus de chances de trouver des deltas plus optimaux.

Il n’est probablement pas utile d’utiliser cette option sur un dépôt donné sans effectuer des tests de performance sur mesure. Cela prend beaucoup plus de temps, et l’optimisation de l’espace/delta qui en résulte peut ou non en valoir la peine. Ne pas l’utiliser du tout est le bon compromis pour la plupart des utilisateurs et leurs dépôts.

git gc' s’efforce de ne pas supprimer les objets qui sont référencés n’importe où dans votre dépôt. En particulier, il conservera non seulement les objets référencés par votre ensemble actuel de branches et de tags, mais aussi les objets référencés par l’index, les branches de suivi à distance, les reflogs (qui peuvent référencer des commits dans des branches qui ont été modifiées ou remontées ultérieurement), et tout ce qui se trouve dans l’espace de nom refs/*. Notez qu’une note (du type de celle créée par git notes) attachée à un objet ne contribue pas à maintenir l’objet en vie. Si vous vous attendez à ce que certains objets soient supprimés et qu’ils ne le sont pas, vérifiez tous ces emplacements et décidez si cela a un sens dans votre cas de supprimer ces références.

D’autre part, lorsque git gc s’exécute en même temps qu’un autre processus, il y a un risque qu’il supprime un objet que l’autre processus utilise mais auquel il n’a pas créé de référence. Cela peut simplement faire échouer l’autre processus ou corrompre le dépôt si l’autre processus ajoute plus tard une référence à l’objet supprimé. Git possède deux fonctionnalités qui atténuent considérablement ce problème :

Toutefois, ces fonctionnalités ne constituent pas une solution complète, de sorte que les utilisateurs qui exécutent des commandes simultanément doivent s’accommoder d’un certain risque de corruption (qui semble faible en pratique).

La commande git gc --auto peut lancer le crochet pre-auto-gc. Voir githooks[5] pour de plus amples informations.

git-prune[1] git-reflog[1] git-repack[1] git-rerere[1]

Fait partie de la suite git[1]

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .