Comme mentionné dans cette réponse SO ,git gc
peut en fait augmenter la taille du repo!
Voir aussi ce fil
Maintenant, git a un mécanisme de sécurité pour ne pas supprimer les objets non référencés immédiatement lors de l'exécution de ' git gc
'.
Par défaut, les objets non référencés sont conservés pendant une période de 2 semaines. Ceci vous permet de récupérer facilement des branches ou des commits supprimés accidentellement, ou d'éviter une course où un objet qui vient d'être créé en cours de création mais pas encore référencé pourrait être supprimé par un 'git gc
' processus exécuté en parallèle.
Donc, pour donner ce délai de grâce aux objets emballés mais non référencés, le processus de reconditionnement pousse ces objets non référencés hors du pack dans leur forme libre afin qu'ils puissent être vieillis et éventuellement élagués.
Les objets qui ne sont plus référencés ne sont généralement pas si nombreux. Avoir 404855 objets non référencés est beaucoup, et être envoyé ces objets en premier lieu via un clone est stupide et un gaspillage complet de bande passante réseau.
Quoi qu'il en soit ... Pour résoudre votre problème, il vous suffit d'exécuter ` git gc
` ' ' avec l' --prune=now
argument pour désactiver cette période de grâce et vous débarrasser immédiatement de ces objets non référencés (sûr uniquement si aucune autre activité git n'a lieu en même temps, ce qui devrait être facile à assurer sur un poste de travail).
Et BTW, en utilisant ' git gc --aggressive
' avec une version ultérieure de git (ou ' git repack -a -f -d --window=250 --depth=250
')
Le même fil mentionne :
git config pack.deltaCacheSize 1
Cela limite la taille du cache delta à un octet (le désactivant effectivement) au lieu de la valeur par défaut de 0, ce qui signifie illimité. Avec cela, je suis capable de reconditionner ce référentiel en utilisant la git repack
commande ci-dessus sur un système x86-64 avec 4 Go de RAM et en utilisant 4 threads (il s'agit d'un quad core). Cependant, l'utilisation de la mémoire résidente atteint près de 3,3 Go.
Si votre machine est SMP et que vous ne disposez pas de suffisamment de RAM, vous pouvez réduire le nombre de threads à un seul:
git config pack.threads 1
De plus, vous pouvez limiter davantage l'utilisation de la mémoire avec le --window-memory argument
to ' git repack
'.
Par exemple, l'utilisation --window-memory=128M
doit conserver une limite supérieure raisonnable sur l'utilisation de la mémoire de recherche delta bien que cela puisse entraîner une correspondance delta moins optimale si le dépôt contient beaucoup de fichiers volumineux.
Sur le front de la branche filtre, vous pouvez considérer (avec prudence) ce script
#!/bin/bash
set -o errexit
# Author: David Underhill
# Script to permanently delete files/folders from your git repository. To use
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2
if [ $# -eq 0 ]; then
exit 0
fi
# make sure we're at the root of git repo
if [ ! -d .git ]; then
echo "Error: must run this script from the root of a git repository"
exit 1
fi
# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD
# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all && git gc --aggressive --prune