Wie in dieser SO-Antwort erwähnt , git gc
kann das Repo tatsächlich vergrößert werden!
Siehe auch diesen Thread
Jetzt hat git einen Sicherheitsmechanismus, um nicht referenzierte Objekte beim Ausführen von ' git gc
' nicht sofort zu löschen .
Standardmäßig werden nicht referenzierte Objekte 2 Wochen lang aufbewahrt. Dies soll Ihnen das Wiederherstellen versehentlich gelöschter Zweige oder Commits erleichtern oder ein Rennen vermeiden, bei dem ein gerade erstelltes Objekt, das gerade erstellt, aber noch nicht referenziert wurde, von einem 'gelöscht werden könnte.git gc
parallel laufenden Prozess .
Um gepackten, aber nicht referenzierten Objekten diese Kulanzfrist zu geben, werden diese nicht referenzierten Objekte durch das Umpacken aus der Packung in ihre lose Form gebracht, damit sie gealtert und schließlich beschnitten werden können.
Objekte, die nicht mehr referenziert werden, sind normalerweise nicht so viele. 404855 nicht referenzierte Objekte zu haben, ist ziemlich viel, und diese Objekte überhaupt über einen Klon zu senden, ist dumm und eine völlige Verschwendung von Netzwerkbandbreite.
Wie auch immer ... Um Ihr Problem zu lösen, müssen Sie einfach ' git gc
' mit dem --prune=now
Argument ausführen, um diese Kulanzfrist zu deaktivieren und diese nicht referenzierten Objekte sofort zu entfernen (nur dann sicher, wenn keine anderen Git-Aktivitäten gleichzeitig stattfinden, die dies sollten auf einer Workstation einfach sicherzustellen sein).
Und übrigens mit ' git gc --aggressive
' mit einer späteren Git-Version (oder ' git repack -a -f -d --window=250 --depth=250
')
Der gleiche Thread erwähnt :
git config pack.deltaCacheSize 1
Dies begrenzt die Delta-Cache-Größe auf ein Byte (wodurch sie effektiv deaktiviert wird) anstelle des Standardwerts 0, was unbegrenzt bedeutet. Damit kann ich das Repository mit dem obigen git repack
Befehl auf einem x86-64-System mit 4 GB RAM und 4 Threads neu packen (dies ist ein Quad-Core). Die Auslastung des residenten Speichers steigt jedoch auf fast 3,3 GB.
Wenn Ihr Computer SMP ist und Sie nicht über genügend RAM verfügen, können Sie die Anzahl der Threads auf nur einen reduzieren:
git config pack.threads 1
Darüber hinaus können Sie die Speichernutzung mit --window-memory argument
to ' git repack
' weiter einschränken .
Beispielsweise --window-memory=128M
sollte die Verwendung eine angemessene Obergrenze für die Verwendung des Delta-Suchspeichers beibehalten, obwohl dies zu einer weniger optimalen Delta-Übereinstimmung führen kann, wenn das Repo viele große Dateien enthält.
Auf der Filter-Zweig-Front können Sie dieses Skript (mit Vorsicht) betrachten
#!/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