SammysHP

Wer SVN nutzt, kennt es: Man hat lokal eine Arbeitskopie (vielleicht sogar nur von einem Teil des Repositorys) mit einer bestimmten Revision. Möchte man in das Log schauen oder zu einer anderen Revision wechseln, benötigt man eine Verbindung zum Server.

Dies ist einer der Gründe, warum ich git bevorzuge: Hier hat man immer alles lokal. Das hilft nicht nur beim offline Arbeiten, sondern auch im Notfall, falls die Daten auf dem Server beschädigt werden. Doch es gibt Situationen, in denen man nicht das ganze Repository braucht, vor allem, wenn es mehrere Gigabyte groß ist.

Wenn die Vergangenheit zur Qual wird

Schnell ist es passiert und man hat eine große Datei committet und auf einen Remote gepusht.¹ Gut, denkt man sich, dann lösche ich die eben wieder. Kleiner wird das Repository dadurch aber nicht und während das bei SVN höchstens den Administrator stört, bemerkt es im Falle von git jeder Nutzer. Ich bin kürzlich wieder auf dieses Problem gestoßen, da ich mich mit QGIS beschäftigt habe und einen Clone mit mehr als 2 GB² herunterladen musste, obwohl das Source-Archiv nur 60 MB groß ist.

Ja, aber es gibt doch git filter-branch! Ja, das stimmt. Damit kann man Dateien in der gesamten History löschen und so das Repository verkleinern. Allerdings werden dabei auch alle Commits neu geschrieben, sodass alte SHA1-Hashes nicht mehr gültig sind. Das neue Repository wäre also inkompatibel mit allen älteren Clones. (Was zudem mit signierten Commits passiert, weiß ich nicht.)

Shallow Clones

Auf meiner Suche nach einer sinnvollen Lösung für das QGIS-Repository bin ich auf eine bzw. zwei Optionen für git clone gestoßen.

Die erste ist --single-branch, welche nur den angegebenen Branch herunterlädt. Ist man also nur an einem älteren Branch interessiert, kann man sich so unter Umständen einige Daten sparen. Da störende Dateien aber üblicherweise schon etwas weiter in der Vergangenheit liegen und damit meistens auch in dem Branch liegen, hilft es nicht viel.

Viel interessanter ist deswegen eine andere Option: --depth n. Hierbei werden nämlich nur die n letzten Commits heruntergeladen. In Verbindung mit --branch lässt sich somit der letzte Stand eines bestimmten Branches clonen. Für QGIS sieht der komplette Befehl dann so aus:

$ git clone --depth 1 --branch release-2_6 git://github.com/qgis/QGIS.git
Cloning into 'QGIS'...
remote: Counting objects: 10452, done.
remote: Compressing objects: 100% (7932/7932), done.
remote: Total 10452 (delta 3505), reused 6142 (delta 2430)
Receiving objects: 100% (10452/10452), 59.60 MiB | 1.13 MiB/s, done.
Resolving deltas: 100% (3505/3505), done.
Checking connectivity... done.

Diese spezielle Form eines Clones hat den Namen shallow clone. Früher gab es dabei noch den Nachteil, dass man von einem solchen Clone weder einen pull noch einen push machen konnte. Seit git 1.9 gibt es diese Beschränkung jedoch nicht mehr.

____________
¹ Wirklich glücklich bin ich mit diesem Denglisch nicht.
² Bevorzugt ihr GB oder GiB?