Also hier ist, was ich bisher herausgefunden habe:Ich konnte keine Dokumentation über dieses versteckte '.tmp-XXXX-Paket' in .git/objects/pack finden Mappe. Alle anderen Threads, die ich finden kann, sind über nicht versteckt Dateien mit tmp_ Präfix im selben Ordner. Die versteckten werden auch eindeutig während der Repack-Aktion erstellt und es ist möglich, dass diese auch hängen bleiben. Ich kann nicht bestätigen, ob das in Git 2.3.0 (auf das ich seitdem aktualisiert habe) noch möglich ist, aber zumindest scheint sich der Speicherplatzbedarf in dieser neueren Version nicht geändert zu haben - gc kann immer noch nicht abgeschlossen werden /umpacken. Durch das Löschen dieser .tmp-Dateien konnte ich meine letzten 4 GB 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 reichten selbst 4 GB nicht aus, um mit gc --agressive neu zu packen . Mein .git Ordner ist nach der Bereinigung 1,1 GB groß, mein gesamtes Repository ist 1,7 GB groß. Die doppelte Größe Ihres Repositorys reicht also möglicherweise nicht für git gc , auch mit der aggressiven Option (die Platz sparen sollte). Also musste ich zuerst mehr Platz von woanders gewinnen.
Schließlich habe ich jetzt Folgendes in meinem Bereinigungsskript (was meiner Meinung nach eine gute Idee sein könnte, es von einem Cron-Job aus aufzurufen):
#!/bin/bash
set -e
#git gc or remove tmp if that fails (because out of disk space)
git gc --aggressive --prune=now || rm -f .git/objects/*/tmp_* && rm -f .git/objects/*/.tmp-*
Ähnliches Szenario (ca. 2,3 G verfügbar), außer git gc selbst würde auch mit fatal: Unable to create '/home/ubuntu/my-app-here/.git/gc.pid.lock': No space left on device fehlschlagen
Was funktionierte, war git prune zuerst und führen Sie dann gc.