seufzen, ok
%Vor%sieht nicht so schlecht aus
%Vor% Also, git gc läuft auf einem tmp-Paket aus, das nur 16MB groß ist, während mein Laufwerk 3GB frei zu haben scheint. Was vermisse ich? Wie kann ich git gc zuverlässiger arbeiten lassen? Ich habe versucht, ohne aggressive Option und --prune anstelle von --prune=now auch die gleiche Geschichte.
Aktualisieren
Wenn ich während der Repack-Aktion einen df -h mache, zeigt das an, dass es jetzt meine gesamte Festplatte benutzt (100% Auslastung). Etwas später schlägt die Repack-Aktion fehl und es verbleibt eine weitere 14MB-Datei im .git / objects / pack / -Ordner. Zur Erinnerung: Meine Pakete verbrauchen insgesamt 580 MB. git repack schafft es irgendwie, 3GB zu verbrauchen, um das zu packen. Ich habe ~ 800MB frei im RAM, nachdem es übrigens getan ist. - Vielleicht nutzt es so viel Arbeitsgedächtnis, dass es den Swap verstopft? Ich denke, meine Frage kommt auf: Gibt es Möglichkeiten, git Repack weniger Ressourcen hungrig machen?
Versionen: git Version 1.7.9.5 unter Ubuntu 12.04
Update 2 Ich habe git auf 2.3 aktualisiert. Habe leider nichts geändert.
%Vor%Update 3
Ok, ich habe gerade etwas entdeckt, das neugierig ist: Das .git -Verzeichnis verwendet tatsächlich viel mehr Speicherplatz als die zuvor gemeldeten 508 MB.
Bei weiterer Überprüfung verwendet .git/objects/pack tatsächlich 4,5 GB. Die Unterschiede liegen in versteckten temporären Dateien, die ich vorher nicht bemerkt habe:
Nun würde ich gerne wissen: Ist es sicher, diese einfach zu löschen?
Hier ist also, was ich bis jetzt herausgefunden habe: Ich konnte keine Dokumentation über diese versteckten '.tmp-XXXX-Pakete' im .git/objects/pack -Ordner finden. Alle anderen Threads, die ich finden kann, sind nicht versteckte Dateien mit tmp_ Präfix im selben Ordner. Die versteckten sind auch während der Repack-Aktion klar erstellt und es ist möglich, dass diese auch hängen bleiben. Ich kann nicht bestätigen, ob das noch in git 2.3.0 möglich ist (auf das ich seither aktualisiert habe), aber zumindest scheint sich der Speicherplatzbedarf in dieser neueren Version nicht geändert zu haben - es kann immer noch nicht GC vervollständigen / packen Durch das Löschen dieser .tmp-Dateien konnte ich meine letzten 4GB wiederherstellen und Git scheint sich danach immer noch gut zu verhalten - Ihre Ergebnisse können jedoch variieren, also stellen Sie bitte sicher, dass Sie eine Sicherungskopie haben, bevor Sie dies tun. Schließlich waren selbst 4 GB nicht genug, um mit gc --agressive umzupacken. Mein .git Ordner ist 1,1 GB nach der Bereinigung, mein gesamtes Repository ist 1,7 GB. Also ist 2x die Größe Ihres Repositories möglicherweise nicht genug für git gc , selbst mit der aggressiven Option (die Speicherplatz sparen sollte). Also musste ich zuerst mehr Platz von anderswo holen.
Endlich, hier ist, was ich in meinem Bereinigungsskript jetzt habe (was ich denke, dass es eine gute Idee wäre, von einem Cron-Job aus aufzurufen):
%Vor%