Veröffentlichung des Versionskontrollsystems Git 2.45.

Nach zwei Monaten Entwicklung wurde die Version 2.45 des verteilten Systems zur Verwaltung von Quelltexten Git veröffentlicht. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionsverwaltungssysteme, das flexible Möglichkeiten für nichtlineare Entwicklungen bietet, die auf Verzweigungen und Zusammenführungen von Branches basieren. Um die Integrität der Historie und die Resistenz gegen nachträgliche Änderungen zu gewährleisten, wird eine implizite Hash-Berechnung der gesamten vorherigen Historie in jedem Commit verwendet; außerdem können digitale Signaturen einzelner Tags und Commits von Entwicklern verifiziert werden. Der Git-Code wird unter der Lizenz GPLv2+ verbreitet.

Im Vergleich zur vorherigen Version wurden in die neue Version 540 Änderungen übernommen, an denen 96 Entwickler mitgewirkt haben, von denen 35 erstmals an der Entwicklung beteiligt waren. Die wichtigsten Neuerungen:

• Es wurde eine vorläufige Unterstützung für das Backend „reftable“ hinzugefügt, um die effiziente Speicherung von Verweisen auf Branches und Tags im Repository zu ermöglichen. Das neue Backend verwendet eine Blockspeicherung, die im Projekt JGit Anwendung findet, und ist optimiert für die Speicherung einer sehr großen Anzahl von Verweisen (traditionelle Formate zur Speicherung von Verweisen führen in Repositories mit vielen Verweisen aufgrund der Ablage einer sehr großen Anzahl von Dateien in einem Verzeichnis zu spürbaren Overhead-Kosten, wenn Verweise im Verzeichnis $GIT_DIR/refs gespeichert werden, oder es ist notwendig, bei jedem Update eine große Datei neu zu schreiben, wenn Verweise in der Datei $GIT_DIR/packed_refs gespeichert werden). Das neue Backend wird aktiviert, indem die Option „—ref-format=reftable“ bei der Initialisierung des Repositories angegeben wird („git init —ref-format=reftable /path/to/repo“), was die Suche, das Lesen und Schreiben in Repositories mit vielen Verweisen beschleunigt.
• Es wurden Mittel bereitgestellt, um die Portabilität zwischen Objekt-IDs auf Basis der Hashes SHA-1 und SHA-256 sicherzustellen. Um den Betrieb mit SHA-1- und SHA-256-Hashes in einem Repository im Rahmen einer schrittweisen Migration zu SHA-256-Hashes zu ermöglichen, wurde ein neues Objektformat „compatibility“ vorgeschlagen, das es ermöglicht, auf Objekte nicht nur über den Haupt-Hash, der bei der Initialisierung des Repositories festgelegt wurde, sondern auch über einen Backup-Hash zuzugreifen. So kann bei der Initialisierung des Repositories das Format SHA-256 gewählt und als Backup der Hash SHA-1 definiert werden: git init —object-format=sha256 /path/to/repo cd /path/to/repo git config extensions.compatObjectFormat sha1
• Der Befehl „git rev-list“ hat die Möglichkeit hinzugefügt, Objekt-IDs anzuzeigen, die im lokalen Repository fehlen, selbst wenn sie in einem Branch oder Tag unerreichbar sind. Dies kann zur Diagnose von Repository-Schäden verwendet werden: git rev-list —missing=print —all | grep ‘^?’ ?70678e7afeacdcba1242793c3d3d28916a2fd152
• Ein neuer Befehl „git reflog list“ wurde hinzugefügt, um bekannte Reflogs und die entsprechenden Links zu Tags und Branches anzuzeigen.
• Die Möglichkeit wurde bereitgestellt, alternative Präfixe für die Ausgabe von „git diff“ festzulegen, die vor dem Dateipfad angezeigt werden und den Zustand vor und nach einer bestimmten Version der Datei kennzeichnen (standardmäßig werden die Präfixe „a/“ und „b/“ verwendet). Neue Parameter diff.srcPrefix und diff.dstPrefix wurden zur Konfiguration hinzugefügt, um eigene Präfixe festzulegen.
• Ein Parameter core.commentString wurde hinzugefügt, um eine Trennzeile zu definieren, die anstelle des Zeichens „#“ zur Ignorierung von Kommentaren in der Commit-Nachricht verwendet wird. Die zuvor verfügbare Einstellung core.commentChar wurde angepasst, um mehrbyte Zeichen als Kommentartrennzeichen zu unterstützen (zuvor wurden nur ASCII-Zeichen unterstützt).
• Der Befehl „git config“ hat die Option „—comment“ erhalten, die es ermöglicht, Kommentare in der Datei .gitconfig zu speichern, um die Bedeutung bestimmter Einstellungen zu erläutern. git config —comment ‘um die Merge-Basis anzuzeigen’ merge.conflictStyle diff3 tail -n 2 .git/config [merge] conflictStyle = diff3 # um die Merge-Basis anzuzeigen
• Der Befehl „git cherry-pick“ hat die Option „—empty“ erhalten, um redundante Commits automatisch zu entfernen, ähnlich der Option „—empty“ in git-rebase und git-am.
• Im Befehl „git checkout -p“ ist die Verwendung des Symbols „@“ als Synonym für den Namen „HEAD“ erlaubt.

Quelle: opennet.ru