Git 2.20.0 bringt neue Features, aber auch Änderungen an vorhandenen Befehlen mit. Details dazu nennt eine gestern veröffentlichte Ankündigung der neuen Version.

Zu den “Notizen zur Rückwärtskompatibilität” gehört zum Beispiel, dass “git branch -l <Name>” nun eine Abkürzung für “git branch –list <Name>” ist. Zuvor ließ sich über das Kürzel beim Anlegen eines neuen Zweiges noch ein Reflog erzeugen. “Git help -a” liefert nun einen ausführlichen (verbose) Output zurück und entspricht damit dem vorherigen Schalter “git help -av”. Nicht zuletzt greift “git send-email” nun Strings, die nach Mailadressen aussehen, wenn der Anhang mit “-by” endet. Ein “–suppress-cc=misc-by” ändert das Verhalten.

Daneben gibt es zahlreiche neue Features. Manche Dateisysteme unterscheiden zum Beispiel nicht zwischen Groß- und Kleinschreibung. Holt “git clone” nun zwei Dateien mit gleichen Namen, die sich nur in der Groß- und Kleinschreibung unterscheiden, ging bislang eine davon verloren. Ein neues Feature versucht, solche Fälle zu entdecken und den Nutzer zu warnen.

Fortschritt anzeigen

Die Option “git format-patch” kennt nun die beiden neuen Schalter “–interdiff” und “–range-diff”. Sie erklären den Unterschied zwischen der aktuellen und der vorherigen Version im Cover Letter. Dabei handelt es sich um eine Extra-E-Mail, die einer Reihe von E-Mails mit den eigentlichen Patches vorausgeht. Apropos E-Mail: “git mailinfo” versucht nun, ein durch den Mailagent beschädigtes Patch automatisch zu reparieren.

Beim Erzeugen einer Commit-Graph-Datei von großen Repositories und wenn das Auffrischen des Index nach Eingabe von “git status” zu lange dauert, zeigt Git nun automatisch eine Fortschrittsanzeige. Anders als das unter Linux bekannt “grep” durchsucht “git grep” Verzeichnisse standardmäßig rekursiv. Der Befehl versteht nun explizit die Optionen “–recursive” und “–no-recursive”. Das Verhalten lässt sich also bei Bedarf ausstellen.

Der Befehl “git checkout -b newbranch [HEAD]” soll einen anderen Commit als HEAD ausgeben. Auch diesen Fall haben die Entwickler nun optimiert. Die Regeln, nach denen “git push” und “git fetch” bestimmt haben, ob sich eine Referenz aktualisieren lässt, waren fehlerhaft und wurden überarbeitet.

Neben diesen erwähnten gibt es zahlreiche weitere Änderungen. Menschen, die viel mit Git arbeiten und die neue Version einsetzen möchten, sollten daher einen Blick auf die Ankündigung der neuen Version und ihre Details werfen.