Was ist neu in Git 2.55.0?

Das Git-Projekt hat kürzlich Git 2.55.0 veröffentlicht. Werfen wir einen Blick auf einige bemerkenswerte Highlights dieses Releases, das auch Beiträge des Git-Teams bei GitLab enthält.

Inhalt:

• git-history(1) lernt fixup
• fsmonitor-Daemon für Linux
• git push zu einer Remote-Gruppe
• Lane-Breite von git log --graph begrenzen
• Rust-Entwicklung im Git-Quellcode
• Schnelleres git-grep(1) und git-cherry(1) in Partial Clones

git-history(1) lernt fixup

In unseren Highlights zu Git 2.54.0 haben wir die Einführung von git-history(1) behandelt. In 2.55.0 wurde ein neuer Subbefehl hinzugefügt: fixup.

Angenommen, einige Änderungen wurden vorgenommen und sollen in einen bestehenden Commit eingearbeitet werden. Der gebräuchlichste Ansatz dafür ist das Erstellen eines Fixup-Commits und dessen automatisches Squashen mit git-rebase(1):

      git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^

    

Dieses Vorgehen in zwei Schritten ist umständlich, insbesondere weil ein interaktives Rebase erforderlich ist. Stattdessen lässt sich der git-history(1)-Befehl fixup verwenden:

      git history fixup <commit-id>

    

Dieser Befehl nimmt die gestagten Änderungen und arbeitet sie in den angegebenen Commit ein. Als zusätzlicher Vorteil werden bei der Verwendung von git-history(1) alle anderen lokalen Branches, die den korrigierten Commit enthalten, ebenfalls aktualisiert. Bei der Arbeit mit gestapelten Branches wird durch das Korrigieren eines Commits im Stack automatisch ein Rebase aller zugehörigen Branches ausgeführt.

Dieses Feature wurde von Patrick Steinhardtimplementiert.

fsmonitor-Daemon für Linux

Bei der Arbeit mit großen Monorepos kann git-status(1) langsam sein, da Git den gesamten Working Tree traversieren muss, um geänderte Dateien zu ermitteln. Um diesen Prozess zu beschleunigen, wurde im Januar 2018 die Einstellung core.fsmonitor in Git 2.16 hinzugefügt. Damals musste ein eigenes Werkzeug wie Watchman bereitgestellt werden. Bei entsprechender Konfiguration läuft dieses Werkzeug im Hintergrund und überwacht Änderungen am Dateisystem. Es informiert Git, dass eine Datei berührt wurde, woraufhin Git prüft, ob die Datei tatsächlich geändert wurde, und den gecachten Status aktualisiert. Wenn git-status(1) aufgerufen wird, kann es den gecachten Status direkt zurückgeben.

Im April 2022 wurde die Einstellung core.fsmonitorgeändert, um einen Boolean-Wert zu akzeptieren. Bei true wird ein in Git integrierter Daemon verwendet – kein Drittanbieter-Werkzeug mehr. Dieser Filesystem-Monitor war jedoch nur für Windows und macOS implementiert, GNU/Linux-Unterstützung fehlte bislang.

Das ändert sich mit Git 2.55, das auch Linux-Unterstützung hinzufügt. Dafür wird inotify(7) verwendet. inotify(7) wurde gegenüber fanotify(7) bevorzugt, da fanotify(7) erhöhte Berechtigungen erfordert. Das bringt jedoch einen kleinen Vorbehalt mit sich: Der fsmonitor muss auf jedes einzelne Verzeichnis im Repository einen Watcher setzen. In einem großen Repository kann das Limit der inotify-Watches (fs.inotify.max_user_watches) erreicht werden, das möglicherweise erhöht werden muss.

Diese Änderungen wurden von Paul Tarjan auf Basis der Arbeit von Eric DeCosta und Marziyeh Esipreheingereicht.

git push zu einer Remote-Gruppe

Vor einiger Zeit hat git-fetch(1) gelernt, von einer Gruppe von Remotes zu fetchen.

Mit dem folgenden Befehl wird eine Remote-Gruppe konfiguriert:

      git config set remotes.forks "origin upstream"

    

Damit lässt sich git-fetch(1) aus dieser „forks"-Gruppe aufrufen, und alle Remotes in der Liste werden abgerufen. Das ist nützlich, um Updates von mehreren Remotes in einem Schritt zu holen.

git-push(1) konnte Remote-Gruppen bislang jedoch nicht verwenden.

In Git 2.55 wird diese Lücke geschlossen: git-push(1) akzeptiert jetzt ebenfalls Remote-Gruppen. Um beispielsweise den main-Branch in die oben genannte Gruppe zu pushen:

      git push forks main

    

Wie bei git-fetch(1) pusht dieser Befehl die angegebenen Refs zu jedem Remote in der Gruppe. Jeder Remote wird unabhängig gepusht und berücksichtigt seine eigene remote.<name>.push-Zuordnung und Mirror-Einstellungen.

Dieses Feature wurde von Usman Akinyemieingereicht und von Junio C Hamano angeregt.

Lane-Breite von git log --graph begrenzen

Die Option --graph von git-log(1) zeichnet eine ASCII-Darstellung der Commit-Historie. In einem Repository mit vielen aktiven Beitragenden kann dieser Graph sehr breit werden. Im git.git-Repository zum Beispiel wächst der Graph nach nur 30 Commits auf neun Lanes Breite:

      * 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | |   621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \ \
| * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_|/
| |/| | | |
* | | | | |   0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \ \
| * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | | | 042221cccb doc: config/sideband: fix description list delimiter
| * | | | | | 3eb61fda62 doc: config: terminate runaway lists
* | | | | | |   49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \ \ \
| * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself
* | | | | | | |   b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \ \ \ \
| * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags

    

Das liegt daran, dass jede Lane bis zu dem Commit weiterläuft, von dem der Branch abgezweigt wurde. Das schiebt die Commit-Nachrichten nach rechts und erschwert das Lesen – besonders wenn die Terminalbreite erreicht wird, wird die Ausgabe unbrauchbar.

Git 2.55 fügt eine neue Option --graph-lane-limit=<n> hinzu, um die Anzahl der gezeichneten Lanes zu begrenzen. Lanes jenseits des Limits werden durch ein ~-Kürzungszeichen ersetzt, sodass ersichtlich bleibt, dass der Graph abgeschnitten wurde:

      git log --graph --graph-lane-limit=5

    

Mit dieser Option für dieselben 30 Commits von oben ergibt sich:

      * 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-window-clang'
|\ \ \ \ \
| * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \~
| * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_~
| |/| | | ~
* | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \~
| * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter
| * | | | ~ 3eb61fda62 doc: config: terminate runaway lists
* | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \~
| * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself
* | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \~
| * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags

    

Die Option macht nur in Kombination mit --graph Sinn. Der Standardwert ist 0 (kein Limit), null und negative Werte werden gleich behandelt – analog zu --max-parents.

Dieses Feature wurde von Pablo Sabatereingereicht.

Rust-Entwicklung im Git-Quellcode

Im März 2025 wurde mit dem Release von Git 2.49 der erste Rust-Code in den Git-Quellcode aufgenommen. Rust-Bindings ermöglichten Rust-Code den Aufruf von libgit. Keiner dieser Rust-Code-Teile wurde jedoch von den Git-Binaries genutzt.

Im November 2025 wurde in Git 2.52 der erste Rust-Produktionscode in Git eingeführt: eine Rust-Implementierung des varint-Subsystems. Dieser Code wird optional kompiliert, wenn der Rust-Compiler verfügbar ist; andernfalls wird die C-Implementierung verwendet. Das war ein Testballon für Distributoren, um ihre Toolchain auf ein künftiges Git-Release vorzubereiten, das Rust voraussetzt.

Anfang dieses Jahres, in Version 2.54, wurde weiterer Rust-Code mit der Einführung des ObjectID-Typs hinzugefügt – als Teil der Bemühungen um Interoperabilität zwischen SHA-1 und SHA-256.

Bis zu diesem Release griffen beide Build-Systeme Make und Meson auf die C-Implementierung zurück, wenn kein Rust-Compiler gefunden wurde. Mit diesem v2.55-Release wird der Rust-Compiler vorausgesetzt, es sei denn, er wird im Build-System explizit deaktiviert.

Hinweis: Das betrifft keine Nutzer von Git. Es betrifft nur diejenigen, die Git aus dem Quellcode kompilieren. Wer Git kompiliert und Rust nicht verwenden möchte, deaktiviert es mit einem dieser Befehle:

      # Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPlease

    

Die Integration von Rust in Git ist ein laufendes (und noch nicht abgeschlossenes) community-weites Effort über mehrere Releases hinweg. Es ist unmöglich, das einer einzelnen Person zuzuschreiben, aber zu den bedeutendsten Beitragenden gehören brian m. carlson, Patrick Steinhardt, Ezekiel Newren und Calvin Wan.

Schnelleres git-grep(1) und git-cherry(1) in Partial Clones

git-clone(1) verfügt über eine Funktion namens Partial Clone. Sie ermöglicht das Anwenden eines Filters auf das, was vom Server übertragen wird. In der Praxis geschieht das mit der --filter-Option:

      git clone --filter=blob:none <remote>

    

Damit wird das Repository geklont, aber ohne Blobs (d. h. ohne den Inhalt der Dateien im Tree). Das kann den Clone erheblich beschleunigen, hat aber den Nachteil, dass Git Blobs später herunterladen muss, wenn andere Befehle den Dateiinhalt lesen. Manche Befehle benötigen dabei sehr viele fehlende Blobs.

git-grep(1) ist einer dieser Befehle, da er den Inhalt von Dateien durchsucht. Angenommen, nach dem Wort „TODO" in der Historie 100 Commits zurück gesucht werden soll:

      git grep TODO HEAD~100

    

Dieser Befehl löst den HEAD~100-Commit und die zugehörigen Trees auf. Diese Trees können jedoch auf Blobs zeigen, die noch nicht heruntergeladen wurden. Bisher wurde jeder Blob einzeln heruntergeladen. Das wurde in Git 2.55 verbessert: Die Blob-Downloads werden jetzt in einem einzigen Verhandlungs-Round-Trip mit dem Server gebündelt.

Dieses Batching ist jetzt sowohl für git-grep(1) als auch für git-cherry(1) implementiert.

Diese Änderung wurde von Elijah Newreneingereicht.

Weiterlesen

Dieser Artikel hat nur einige der Beiträge von GitLab und der breiteren Git-Community für dieses Release hervorgehoben. Weitere Details sind in der offiziellen Release-Ankündigung des Git-Projekts zu finden. Außerdem lohnt ein Blick auf die früheren Git-Release-Blogbeiträge, die weitere Highlights der Beiträge von GitLab-Teammitgliedern zeigen.