Come accennato in questa risposta SO , git gcpuò effettivamente aumentare la dimensione del repo!
Vedi anche questo thread
Ora git ha un meccanismo di sicurezza per non eliminare subito gli oggetti non referenziati durante l'esecuzione ' git gc'.
Per impostazione predefinita, gli oggetti non referenziati vengono conservati per un periodo di 2 settimane. Questo per semplificare il recupero di rami o commit cancellati accidentalmente o per evitare una corsa in cui un oggetto appena creato in fase di elaborazione ma non ancora referenziato potrebbe essere cancellato da un git gcprocesso " " in esecuzione in parallelo.
Quindi, per concedere quel periodo di grazia agli oggetti imballati ma non referenziati, il processo di reimballaggio spinge quegli oggetti non referenziati fuori dallo zaino nella loro forma sciolta in modo che possano essere invecchiati ed eventualmente potati.
Gli oggetti che diventano non referenziati di solito non sono poi così tanti. Avere 404855 oggetti non referenziati è abbastanza, e l'invio di quegli oggetti in primo luogo tramite un clone è stupido e un completo spreco di larghezza di banda di rete.
Comunque ... Per risolvere il tuo problema, devi semplicemente eseguire ' git gc' con l' --prune=nowargomento per disabilitare quel periodo di grazia e sbarazzarti immediatamente di quegli oggetti non referenziati (sicuro solo se non si svolgono altre attività git allo stesso tempo, cosa che dovrebbe essere facile da garantire su una workstation).
E BTW, usando " git gc --aggressive" con una versione successiva di git (o " git repack -a -f -d --window=250 --depth=250")
Lo stesso thread menziona :
git config pack.deltaCacheSize 1
Ciò limita la dimensione della cache delta a un byte (disabilitandola efficacemente) invece del valore predefinito di 0 che significa illimitato. Con ciò sono in grado di reimpacchettare quel repository usando il git repackcomando sopra su un sistema x86-64 con 4 GB di RAM e utilizzando 4 thread (questo è un quad core). L'utilizzo della memoria residente cresce fino a quasi 3,3 GB.
Se la tua macchina è SMP e non hai RAM sufficiente, puoi ridurre il numero di thread a uno solo:
git config pack.threads 1
Inoltre, puoi limitare ulteriormente l'utilizzo della memoria con il --window-memory argument" git repack".
Ad esempio, l'utilizzo --window-memory=128Mdovrebbe mantenere un limite superiore ragionevole sull'utilizzo della memoria della ricerca delta sebbene ciò possa comportare una corrispondenza delta meno ottimale se il repository contiene molti file di grandi dimensioni.
Sul fronte del ramo del filtro, puoi considerare (con cautela) questo 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