News

Git-Update: Was sich in der neuen Feature-Version 2.21 ändert

(Grafik: Shutterstock/Bakhtiar Zein)

Die Open-Source-Versionsverwaltung Git hat erneut ein Update erhalten. Das Feature-Release 2.21 kommt mit neuen Funktionen für den Log- und Verbesserungen für den Klon-Befehl.

Lesbares Datum in Log

Mit git log werden alle durchgeführten Commits ausgegeben. Neben der Beschreibung und dem Autor wird dabei auch jeweils ein Zeitstempel angezeigt. Standardmäßig wird der jedoch beispielsweise wie folgt ausgegeben: Sun Sep 2 16:31:10 2018 +0200. Das gibt die Zeit sehr präzise wieder. Doch einige der Informationen sind überflüssig, da sie nicht immer relevant sind. Deswegen gibt es die Möglichkeit, das Datumsformat zu ändern.

Mit --date=relative ging das bereits zuvor. Damit wird zum Beispiel 11 days ago ausgegeben. Doch welcher Wochentag war das nochmal? Vor oder nach dem Meeting? Mit Git 2.21 gibt es jetzt eine weitere Option. --date=human zeigt das Datum flexibler an. Je nachdem, wie weit der Commit in der Vergangenheit liegt, wird ein passendes, gut leserliches Format gewählt: relativ wenn es nur ein paar Stunden her ist, mit Tagesangabe, wenn es kürzlich war – und ist es lange her, so wird nur das Datum ausgegeben.

Der Commit-Log kann jetzt mit einem besser lesbaren Datum angezeigt werden. (Screenshot: t3n.de)
Der Commit-Log kann jetzt mit einem besser lesbaren Datum angezeigt werden. (Screenshot: t3n)

In der neuen Git-Version gibt es zusätzlich die Möglichkeit, das normale, maschinenlesbarere Format auszugeben, sollte die Ausgabe nicht auf einem Terminal-Pager stattfinden. Dafür wird --date=auto:human angehängt. In der Terminal-Ausgabe ändert sich nichts. Schreibt man die Ausgabe jedoch beispielsweise in eine Textdatei, wird das Standardformat gewählt.

Mit „auto“ gibt Git außerhalb von Terminal-Pagern wieder das Standardformat aus. (Screenshot: t3n.de)
Mit „auto“ gibt Git außerhalb von Terminal-Pagern wieder das Standardformat aus. (Screenshot: t3n)

Kollision wenn Dateisystem Case-Insensitive

Wird ein Repository geklont, kann es durchaus vorkommen, dass beim anschließenden Aufruf von git status einige Dateien erscheinen, die schon bearbeitet wurden. Sollte das Dateisystem des Betriebssystems Case-Insensitive sein – also Groß- und Kleinschreibung bei der Benennung von Dateien ignorieren –, so kann das zu Problemen führen. Gibt es nämlich mehrere Dateien im selben Verzeichnis, die außer der unterschiedlichen Groß- und Kleinschreibung gleich benannt sind, kann Git in einem solchen Fall nur eine der beiden Dateien auschecken.

In älteren Git-Versionen gab es eben genau dann ein Problem. Mit Git 2.21 kommt beim Durchführen von git clone zumindest eine warnende Meldung. Das Problem beheben kann Git selbst bislang noch nicht. Gerade wenn ihr auf mehreren Geräten an einem Projekt arbeiten wollt, sollten sich Dateinamen immer komplett unterscheiden – und zwar Case-Insensitive.

Zahlreiche Performance-Verbesserungen im Detail

Auch wurden in der Version typischerweise Performance-Optimierungen, Code-Aufräumarbeiten im Hintergrund und Bugfixes für die vorangegangenen Version 2.20 angegangen. Die Liste aller Änderungen kann hier eingesehen werden.

Mehr Lesestoff zum Thema Git:

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung