Git speichert einen 16 MB großen Quellcode in nur 1,6 MB

How big is a Git commit?

Git komprimiert Objekte mit zlib und packt sie später in Packfiles. Ein Experiment zeigt: Ein leerer Repo belegt 64 KB, ein Commit mit 250 winzigen Dateien kostet 47 KB, und eine 3-Byte-Änderung in einem Ein-Datei-Repo schlägt mit 8 KB zu Buche. Bei großen Dateien ist die Ersparnis enorm: Eine 583 KB große Binärdatei belegt 300 KB, eine 16,4 MB große Quelldatei nur 1,6 MB. Der Overhead kleiner Commits hängt von der Verzeichnisstruktur ab.

Also braucht man 1,6 MB, um eine 16,4 MB große Quelldatei zu committen! Ich hatte erwartet, dass Text gut komprimiert, aber das ist wirklich beeindruckend.
  1. cocoto

    > Die du-Optionen sind: s zum Zusammenfassen und b zum Anzeigen von Bytes.

    Kleine Anmerkung: Verwende lange Optionen, und deine Codebeispiele werden selbsterklärend!

  2. nathanpankon

    Ich habe damit herumgespielt, eine Git-Alternative zu bauen, die auf den Workflow zugeschnitten war. Ich habe sie nicht komplett aufgegeben, aber meine Kernidee war, dass man einen AST-Pfad verwenden kann, um die Daten weiter zu komprimieren.

    Wie du sagst, ist Git wirklich effizient, und obwohl ich mit etwas Kritik herangegangen bin – wegen der Arbeit (dem Chaos), die Chromium ist, und dem tiefen Hacken, das ich dort betrieben habe, um Dinge zwischen Versionen zu reparieren, ohne einen kompletten Rebuild zu erzwingen –

    bin ich zu dem Schluss gekommen, dass mein Ansatz als Komprimierungsalternative nicht lohnenswert war. Git hat einen besseren Job gemacht!

    Wie auch immer, hier ist der Versuch: https://github.com/pankon/gat

  3. jamesblonde

    Git wurde mit Annahmen über lokalen Dateispeicher entworfen, die es schwierig machen, Daten in einem verteilten Dateisystem zu speichern. Wir haben unser verteiltes Dateisystem HopsFS gebaut, um Daten in S3 zu speichern. Um performantes Git in FUSE zu unterstützen, treffen unsere Schreibvorgänge auf entfernte NVMe-Festplatten und synchronisieren asynchron mit S3 (man kann auf NVMe replizieren oder einfach Fehlerwiederherstellung betreiben). Früher haben wir entfernte NVMe-Festplatten als Write-Through-Cache verwendet, aber das funktioniert mit Git nicht, die S3-Latenz ist zu hoch.

Mehr von diesem Tag

2026-10-11