145M = .git / objets / pack /

J'ai écrit un script pour additionner les tailles des différences de chaque commit et du commit avant de revenir en arrière depuis la pointe de chaque branche. J'obtiens 129 Mo, ce qui est sans compression et sans tenir compte des mêmes fichiers dans les branches et de l'historique commun entre les branches.

Git prend toutes ces choses en compte, donc je m'attendrais à un dépôt beaucoup plus petit. Alors, pourquoi .git est-il si grand?

J'ai fait:

git fsck --full
git gc --prune=today --aggressive
git repack

Pour répondre au nombre de fichiers / commits, j'ai 19 branches environ 40 fichiers chacune. 287 commits, trouvés en utilisant:

git log --oneline --all|wc -l

Cela ne devrait pas prendre des dizaines de mégaoctets pour stocker des informations à ce sujet.

J'ai récemment extrait le mauvais référentiel distant dans le local ( git remote add ...et git remote update). Après avoir supprimé la référence distante, les branches et les balises indésirables, j'avais encore 1,4 Go (!) D'espace gaspillé dans mon référentiel. Je n'ai pu m'en débarrasser qu'en le clonant avec git clone file:///path/to/repository. Notez que le file://fait toute la différence lors du clonage d'un référentiel local - seuls les objets référencés sont copiés, pas toute la structure de répertoires.

Edit: Voici la doublure d'Ian pour recréer toutes les branches dans le nouveau repo:

d1=#original repo
d2=#new repo (must already exist)
cd $d1
for b in $(git branch | cut -c 3-)
do
    git checkout $b
    x=$(git rev-parse HEAD)
    cd $d2
    git checkout -b $b $x
    cd $d1
done

Quelques scripts que j'utilise:

git-fatfiles

git rev-list --all --objects | \
    sed -n $(git rev-list --objects --all | \
    cut -f1 -d' ' | \
    git cat-file --batch-check | \
    grep blob | \
    sort -n -k 3 | \
    tail -n40 | \
    while read hash type size; do 
         echo -n "-e s/$hash/$size/p ";
    done) | \
    sort -n -k1

...
89076 images/screenshots/properties.png
103472 images/screenshots/signals.png
9434202 video/parasite-intro.avi

Si vous voulez plus de lignes, consultez également la version Perl dans une réponse voisine: https://stackoverflow.com/a/45366030/266720

git-eradicate (pour video/parasite.avi):

git filter-branch -f  --index-filter \
    'git rm --force --cached --ignore-unmatch video/parasite-intro.avi' \
     -- --all
rm -Rf .git/refs/original && \
    git reflog expire --expire=now --all && \
    git gc --aggressive && \
    git prune

Remarque: le deuxième script est conçu pour supprimer complètement les informations de Git (y compris toutes les informations des reflogs). Utiliser avec précaution.

git gcfait déjà un git repack, il n'y a donc aucun sens à reconditionner manuellement à moins que vous ne lui passiez des options spéciales.

La première étape consiste à voir si la majorité de l'espace est (comme ce serait normalement le cas) votre base de données d'objets.

git count-objects -v

Cela devrait donner un rapport sur le nombre d'objets décompressés dans votre référentiel, l'espace qu'ils occupent, le nombre de fichiers pack dont vous disposez et l'espace qu'ils occupent.

Idéalement, après un reconditionnement, vous n'auriez aucun objet décompressé et un fichier de pack mais il est parfaitement normal d'avoir des objets qui ne sont pas directement référencés par les branches actuelles toujours présents et décompressés.

Si vous avez un seul gros paquet et que vous voulez savoir ce qui prend de la place, vous pouvez lister les objets qui composent le paquet ainsi que la façon dont ils sont stockés.

git verify-pack -v .git/objects/pack/pack-*.idx

Notez que verify-packprend un fichier d'index et non le fichier de pack lui-même. Cela donne un rapport de chaque objet dans le pack, sa taille réelle et sa taille emballée ainsi que des informations sur s'il a été `` deltifié '' et si c'est le cas l'origine de la chaîne delta.

Pour voir s'il y a des objets anormalement grands dans votre référentiel, vous pouvez trier la sortie numériquement sur la troisième des quatrième colonnes (par exemple | sort -k3n).

À partir de cette sortie, vous pourrez voir le contenu de n'importe quel objet à l'aide de la git showcommande, bien qu'il ne soit pas possible de voir exactement où dans l'historique de validation du référentiel l'objet est référencé. Si vous devez faire cela, essayez quelque chose à partir de cette question .

Juste pour info, la principale raison pour laquelle vous pouvez vous retrouver avec des objets indésirables conservés est que git maintient un reflog.

Le reflog est là pour sauver vos fesses lorsque vous supprimez accidentellement votre branche principale ou que vous endommagez d'une manière ou d'une autre de manière catastrophique votre référentiel.

Le moyen le plus simple de résoudre ce problème est de tronquer vos reflogs avant de les compresser (assurez-vous simplement de ne jamais vouloir revenir à l'un des commits du reflog).

git gc --prune=now --aggressive
git repack

Ceci est différent du fait git gc --prune=todayque tout le reflog expire immédiatement.

Si vous voulez trouver les fichiers qui prennent de l'espace dans votre référentiel git, exécutez

git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5

Ensuite, extrayez la référence blob qui occupe le plus d'espace (la dernière ligne) et vérifiez le nom de fichier qui prend autant d'espace

git rev-list --objects --all | grep <reference>

Cela peut même être un fichier avec lequel vous avez supprimé git rm, mais git s'en souvient car il y a encore des références, telles que des balises, des télécommandes et des reflog.

Une fois que vous savez de quel fichier vous voulez vous débarrasser, je vous recommande d'utiliser git forget-blob

https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/

C'est facile à utiliser, il suffit de faire

git forget-blob file-to-forget

Cela supprimera toutes les références de git, supprimera l'objet blob de chaque commit de l'historique et exécutera un garbage collection pour libérer de l'espace.

Le script git-fatfiles de la réponse de Vi est charmant si vous voulez voir la taille de tous vos blobs, mais il est si lent qu'il est inutilisable. J'ai supprimé la limite de sortie de 40 lignes et j'ai essayé d'utiliser toute la RAM de mon ordinateur au lieu de finir. Je l'ai donc réécrit: c'est des milliers de fois plus rapide, a ajouté des fonctionnalités (facultatives) et un bogue étrange a été supprimé - l'ancienne version donnerait des comptes inexacts si vous additionnez la sortie pour voir l'espace total utilisé par un fichier.

#!/usr/bin/perl
use warnings;
use strict;
use IPC::Open2;
use v5.14;

# Try to get the "format_bytes" function:
my $canFormat = eval {
    require Number::Bytes::Human;
    Number::Bytes::Human->import('format_bytes');
    1;
};
my $format_bytes;
if ($canFormat) {
    $format_bytes = \&format_bytes;
}
else {
    $format_bytes = sub { return shift; };
}

# parse arguments:
my ($directories, $sum);
{
    my $arg = $ARGV[0] // "";
    if ($arg eq "--sum" || $arg eq "-s") {
        $sum = 1;
    }
    elsif ($arg eq "--directories" || $arg eq "-d") {
        $directories = 1;
        $sum = 1;
    }
    elsif ($arg) {
        print "Usage: $0 [ --sum, -s | --directories, -d ]\n";
        exit 1;
    } 
}

# the format is [hash, file]
my %revList = map { (split(' ', $_))[0 => 1]; } qx(git rev-list --all --objects);
my $pid = open2(my $childOut, my $childIn, "git cat-file --batch-check");

# The format is (hash => size)
my %hashSizes = map {
    print $childIn $_ . "\n";
    my @blobData = split(' ', <$childOut>);
    if ($blobData[1] eq 'blob') {
        # [hash, size]
        $blobData[0] => $blobData[2];
    }
    else {
        ();
    }
} keys %revList;
close($childIn);
waitpid($pid, 0);

# Need to filter because some aren't files--there are useless directories in this list.
# Format is name => size.
my %fileSizes =
    map { exists($hashSizes{$_}) ? ($revList{$_} => $hashSizes{$_}) : () } keys %revList;


my @sortedSizes;
if ($sum) {
    my %fileSizeSums;
    if ($directories) {
        while (my ($name, $size) = each %fileSizes) {
            # strip off the trailing part of the filename:
            $fileSizeSums{$name =~ s|/[^/]*$||r} += $size;
        }
    }
    else {
        while (my ($name, $size) = each %fileSizes) {
            $fileSizeSums{$name} += $size;
        }
    }

    @sortedSizes = map { [$_, $fileSizeSums{$_}] }
        sort { $fileSizeSums{$a} <=> $fileSizeSums{$b} } keys %fileSizeSums;
}
else {
    # Print the space taken by each file/blob, sorted by size
    @sortedSizes = map { [$_, $fileSizes{$_}] }
        sort { $fileSizes{$a} <=> $fileSizes{$b} } keys %fileSizes;

}

for my $fileSize (@sortedSizes) {
    printf "%s\t%s\n", $format_bytes->($fileSize->[1]), $fileSize->[0];
}

Nommez ce git-fatfiles.pl et exécutez-le. Pour voir l'espace disque utilisé par toutes les révisions d'un fichier, utilisez l' --sumoption. Pour voir la même chose, mais pour les fichiers dans chaque répertoire, utilisez l' --directoriesoption. Si vous installez le numéro :: Octets :: Human module CPAN (run "CPAN :: Nombre Bytes :: humaines"), les tailles seront formatées: "21M /path/to/file.mp4".

Êtes-vous sûr de ne compter que les fichiers .pack et non les fichiers .idx? Ils sont dans le même répertoire que les fichiers .pack, mais ne contiennent aucune donnée du référentiel (comme l'indique l'extension, ce ne sont rien de plus que des index pour le pack correspondant - en fait, si vous connaissez la commande correcte, vous pouvez recréez-les facilement à partir du fichier pack, et git lui-même le fait lors du clonage, car seul un fichier pack est transféré en utilisant le protocole git natif).

En tant qu'échantillon représentatif, j'ai jeté un coup d'œil à mon clone local du référentiel linux-2.6:

$ du -c *.pack
505888  total

$ du -c *.idx
34300   total

Ce qui indique qu'une expansion d'environ 7% devrait être courante.

Il y a aussi les fichiers à l'extérieur objects/; d'après mon expérience personnelle, parmi eux indexet gitk.cacheont tendance à être les plus importants (totalisant 11 millions de dollars dans mon clone du dépôt linux-2.6).

Les autres objets git stockés dans .gitincluent des arbres, des commits et des balises. Les validations et les balises sont petites, mais les arbres peuvent devenir volumineux, en particulier si vous avez un très grand nombre de petits fichiers dans votre référentiel. Combien de fichiers et combien de commits avez-vous?

Avez-vous essayé d'utiliser git repack ?

avant de faire git filter-branch & git gc, vous devriez revoir les balises présentes dans votre dépôt. Tout système réel qui a un marquage automatique pour des choses comme l'intégration continue et les déploiements rendra les objets non désirés encore référencés par ces balises, par conséquent gc ne peut pas les supprimer et vous vous demanderez toujours pourquoi la taille du dépôt est toujours si grande.

La meilleure façon de se débarrasser de tous les éléments indésirables est d'exécuter git-filter & git gc, puis de pousser master vers un nouveau dépôt nu. Le nouveau repo nu aura l'arbre nettoyé.

Cela peut arriver si vous avez accidentellement ajouté un gros morceau de fichiers et les avez mis en scène, sans nécessairement les valider. Cela peut se produire dans une railsapplication lorsque vous exécutez bundle install --deploymentet accidentellement git add .alors vous voir tous les fichiers ajoutés sous vendor/bundlevous les désindexer mais ils déjà entré dans l' histoire git, vous devez appliquer la réponse de Vi et le changement video/parasite-intro.avipar vendor/bundlepuis exécutez la deuxième commande qu'il fournit.

Vous pouvez voir la différence avec git count-objects -vlaquelle dans mon cas avant d'appliquer le script avait un pack de taille: de 52K et après l'application, il était de 3,8K.

Cela vaut la peine de vérifier le stacktrace.log. Il s'agit essentiellement d'un journal des erreurs pour le suivi des commits qui ont échoué. J'ai récemment découvert que mon stacktrace.log était de 65,5 Go et mon application de 66,7 Go.