Beschreibung: Was „Not enough disk space to clone the repository“ bedeutet, warum Repositorys riesig werden und wie man ohne vollständigen Download arbeitet.
Eigentlich sollten nur ein paar Zeilen geändert werden. Stattdessen meldet das Werkzeug, dass zum Klonen des Repositorys nicht genug Speicherplatz vorhanden ist.
Ist der Code kaputt? Nein. Der Arbeitsumgebung, die die Kopie aufnehmen soll, fehlt Speicherplatz. Daraus folgt nicht, dass Dateien auf GitHub verschwunden sind.
In einem konkreten Fall meldete die GitHub-API eine Repository-Größe von ungefähr 9 GB. Man bestellt einen Schraubenzieher und bekommt gleich den ganzen Baumarkt geliefert, samt Regalen.
Was die Fehlermeldung wirklich belegt
Der Kopiervorgang scheiterte an der verfügbaren Speicherkapazität. Aus der Meldung allein erfährt man weder den freien Platz noch die bereits übertragene Datenmenge oder den Anteil aktueller Dateien gegenüber alten Versionen.
Die rund 9 GB sind eine gerundete Größenangabe der API, keine Messung der fehlgeschlagenen lokalen Kopie. Heruntergeladene Daten, ausgepackte Dateien und temporäre Arbeitsbereiche können unterschiedlich viel Platz benötigen.
Warum ein Repository so groß wird
Git verwaltet auch frühere Dateiversionen. Früher eingecheckte große Bilder, Sicherungen und automatisch erzeugte Dateien können die Historie weiter aufblähen. Ein Projekt mit vielen Artikeln, Übersetzungen, Bildern und Ausgabe-Dateien kann zusätzlich einen großen aktuellen Dateibestand besitzen.
Deshalb gilt: Aktuelle Dateien und historische Daten getrennt messen. Erst dann lässt sich die Hauptursache benennen.
GitHub empfiehlt handhabbare Repository-Größen und nennt unter anderem 10 GB als empfohlenes Maximum für den Speicherverbrauch des .git-Verzeichnisses auf dem Datenträger. Das ist kein automatischer Klon-Stopp bei exakt 10 GB; außerdem muss der API-Wert nicht dieselbe Messgröße darstellen.
Für eine Datei braucht man kein ganzes Lagerhaus
Eine frische Arbeitsumgebung hilft möglicherweise, wenn die alte durch temporäre Dateien vollgelaufen ist. Ist die Quelle selbst riesig, kann der Fehler zurückkehren.
Wer nur eine Datei lesen oder ändern will, kann bei passenden Berechtigungen die Datei-API von GitHub nutzen. Falls Git notwendig ist, lässt sich der anfängliche Umfang reduzieren:
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
Dadurch werden weniger historische Versionen geladen, Dateiinhalte erst bei Bedarf geholt und anfangs weniger Pfade ausgecheckt. Eine Erfolgsgarantie ist das nicht. Manche Vorgänge, die die vollständige Historie benötigen, sind eingeschränkt.
Der riskante Schnellschuss
Die Git-Historie nicht einfach löschen oder umschreiben. Das kann andere Arbeitskopien, alte Verweise und Automatisierungen beschädigen. Zuerst freien Speicher messen, große aktuelle Dateien und historische Objekte ermitteln und vor zerstörerischen Eingriffen Sicherungen anlegen.
Die Pointe
Auftrag: „Ändere diese Datei.“ Geplanter Transport: „Zieh mit dem 9-GB-Lagerhaus um.“
Warum für eine einzelne Datei jedes Mal das ganze Lager transportieren? Manchmal ist nicht die Festplatte zu klein, sondern die Transportmethode zu groß.
Quellen: GitHub-Empfehlungen, Umgang mit großen Dateien, Git-clone-Dokumentation.
