English ▾ Themen ▾ Neueste Version ▾ git-commit-graph zuletzt aktualisiert in 2.52.0

NAME

git-commit-graph - Git-Commit-Graph-Dateien schreiben und überprüfen

SYNOPSIS

git commit-graph verify [--object-dir <dir>] [--shallow] [--[no-]progress]
git commit-graph write [--object-dir <dir>] [--append]
			[--split[=<strategy>]] [--reachable | --stdin-packs | --stdin-commits]
			[--changed-paths] [--[no-]max-new-filters <n>] [--[no-]progress]
			<split-options>

BESCHREIBUNG

Verwalten Sie die serialisierte Commit-Graph-Datei.

OPTIONEN

--object-dir

Verwenden Sie das angegebene Verzeichnis für den Speicherort von Pack-Dateien und der Commit-Graph-Datei. Dieser Parameter dient dazu, den Speicherort eines Alternativspeichers anzugeben, der nur das Objektverzeichnis und nicht ein vollständiges .git-Verzeichnis enthält. Die Commit-Graph-Datei wird im Verzeichnis <dir>/info erwartet und die Pack-Dateien im Verzeichnis <dir>/pack. Wenn das Verzeichnis nicht in einen absoluten Pfad umgewandelt werden kann oder kein bekanntes Objektverzeichnis darstellt, wird git commit-graph ... mit einem Nicht-Null-Status beendet.

--progress
--no-progress

Fortschritt explizit ein- oder ausschalten. Wenn keiner der beiden angegeben ist, wird der Fortschritt angezeigt, wenn die Standardfehlerausgabe mit einem Terminal verbunden ist.

BEFEHLE

write

Schreibt eine Commit-Graph-Datei basierend auf den in den Pack-Dateien gefundenen Commits. Wenn die Konfigurationsoption core.commitGraph deaktiviert ist, gibt dieser Befehl eine Warnung aus und kehrt dann erfolgreich zurück, ohne eine Commit-Graph-Datei zu schreiben.

Mit der Option --stdin-packs wird der neue Commit-Graph durch Traversieren von Objekten nur in den angegebenen Pack-Indizes generiert. (Kann nicht mit --stdin-commits oder --reachable kombiniert werden.)

Mit der Option --stdin-commits wird der neue Commit-Graph durch Traversieren von Commits generiert, beginnend mit den in stdin als Liste von OIDs in Hexadezimalform, eine OID pro Zeile, angegebenen Commits. OIDs, die auf Nicht-Commits verweisen (entweder direkt oder durch Abziehen von Tags), werden stillschweigend ignoriert. OIDs, die fehlerhaft sind oder nicht existieren, führen zu einem Fehler. (Kann nicht mit --stdin-packs oder --reachable kombiniert werden.)

Mit der Option --reachable wird der neue Commit-Graph durch Traversieren von Commits generiert, beginnend bei allen Referenzen. (Kann nicht mit --stdin-commits oder --stdin-packs kombiniert werden.)

Mit der Option --append werden alle Commits einbezogen, die in der bestehenden Commit-Graph-Datei vorhanden sind.

Mit der Option --changed-paths werden Informationen über die zwischen einem Commit und seinem ersten Elternteil geänderten Pfade berechnet und geschrieben. Dieser Vorgang kann bei großen Repositories einige Zeit in Anspruch nehmen. Er bietet signifikante Leistungssteigerungen beim Abrufen des Verlaufs eines Verzeichnisses oder einer Datei mit git log -- <path>. Wenn diese Option angegeben wird, wird bei zukünftigen Schreibvorgängen des Commit-Graphen automatisch davon ausgegangen, dass diese Option beabsichtigt war. Verwenden Sie --no-changed-paths, um das Speichern dieser Daten zu stoppen. --changed-paths wird durch die Konfiguration commitGraph.changedPaths=true impliziert.

Mit der Option --max-new-filters=<n> werden höchstens n neue Bloom-Filter generiert (wenn --changed-paths angegeben ist). Wenn n -1 ist, wird keine Begrenzung durchgesetzt. Nur Commits, die in der neuen Schicht vorhanden sind, zählen für dieses Limit. Um Bloom-Filter nachträglich über frühere Schichten zu berechnen, wird empfohlen, --split=replace zu verwenden. Überschreibt die Konfiguration commitGraph.maxNewFilters.

Mit der Option --split[=<strategy>] wird der Commit-Graph als Kette mehrerer Commit-Graph-Dateien geschrieben, die in <dir>/info/commit-graphs gespeichert sind. Die Commit-Graph-Schichten werden basierend auf der Strategie und anderen Aufteilungsoptionen zusammengeführt. Die neuen Commits, die noch nicht im Commit-Graph enthalten sind, werden in einer neuen "Tip"-Datei hinzugefügt. Diese Datei wird mit der vorhandenen Datei zusammengeführt, wenn die folgenden Zusammenführungsbedingungen erfüllt sind

  • Wenn --split=no-merge angegeben ist, wird nie eine Zusammenführung durchgeführt, und die übrigen Optionen werden ignoriert. --split=replace überschreibt die vorhandene Kette mit einer neuen. Ein bloßes --split deferiert auf die übrigen Optionen. (Beachten Sie, dass das Zusammenführen einer Kette von Commit-Graphen die vorhandene Kette durch eine Kette der Länge 1 ersetzt, wobei der erste und einzige inkrementelle Teil den gesamten Graphen enthält).

  • Wenn --size-multiple=<X> nicht angegeben ist, sei X gleich 2. Wenn die neue Tip-Datei N Commits hätte und die vorherige Tip-Datei M Commits hätte und X mal N größer als M wäre, werden stattdessen die beiden Dateien zu einer einzigen Datei zusammengeführt.

  • Wenn --max-commits=<M> mit M als positive ganze Zahl angegeben ist und die neue Tip-Datei mehr als M Commits hätte, werden stattdessen die neue Tip-Datei mit der vorherigen Tip-Datei zusammengeführt.

    Schließlich, wenn --expire-time=<datetime> nicht angegeben ist, sei datetime die aktuelle Zeit. Nach dem Schreiben des aufgeteilten Commit-Graphen werden alle ungenutzten Commit-Graphen gelöscht, deren Änderungszeiten älter als datetime sind.

verify

Liest die Commit-Graph-Datei und überprüft deren Inhalt gegen die Objektdatenbank. Wird zur Überprüfung auf beschädigte Daten verwendet.

Mit der Option --shallow wird nur die Tip-Commit-Graph-Datei in einer Kette von aufgeteilten Commit-Graphen überprüft.

BEISPIELE

  • Schreibt eine Commit-Graph-Datei für die gepackten Commits in Ihrem lokalen .git-Verzeichnis.

    $ git commit-graph write

  • Schreibt eine Commit-Graph-Datei, die die aktuelle Commit-Graph-Datei erweitert, indem Commits in <pack-index> verwendet werden.

    $ echo <pack-index> | git commit-graph write --stdin-packs

  • Schreibt eine Commit-Graph-Datei, die alle erreichbaren Commits enthält.

    $ git show-ref -s | git commit-graph write --stdin-commits

  • Schreibt eine Commit-Graph-Datei, die alle Commits in der aktuellen Commit-Graph-Datei zusammen mit denen enthält, die von HEAD erreichbar sind.

    $ git rev-parse HEAD | git commit-graph write --stdin-commits --append

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

commitGraph.generationVersion

Gibt den Typ der Generierungsnummernversion an, die beim Schreiben oder Lesen der Commit-Graph-Datei verwendet werden soll. Wenn Version 1 angegeben wird, werden die korrigierten Commit-Daten nicht geschrieben oder gelesen. Standardmäßig 2.

commitGraph.maxNewFilters

Gibt den Standardwert für die Option --max-new-filters von git commit-graph write an (siehe git-commit-graph[1]).

commitGraph.changedPaths

Wenn true, berechnet und schreibt git commit-graph write standardmäßig geänderte Pfad-Bloom-Filter, was der Angabe von --changed-paths entspricht. Wenn false oder nicht gesetzt, werden geänderte Pfad-Bloom-Filter während git commit-graph write nur geschrieben, wenn die Filter bereits in der aktuellen Commit-Graph-Datei vorhanden sind. Dies entspricht dem Standardverhalten von git commit-graph write ohne die Option --[no-]changed-paths. Zum Überschreiben einer Commit-Graph-Datei ohne Filter verwenden Sie die Option --no-changed-paths. Die Kommandozeilenoption --[no-]changed-paths hat immer Vorrang vor dieser Konfiguration. Standardmäßig nicht gesetzt.

commitGraph.readChangedPaths

Veraltet. Entspricht commitGraph.changedPathsVersion=-1, wenn true, und commitGraph.changedPathsVersion=0, wenn false. (Wenn commitGraph.changedPathVersion ebenfalls gesetzt ist, hat commitGraph.changedPathsVersion Vorrang.)

commitGraph.changedPathsVersion

Gibt die Version der geänderten Pfad-Bloom-Filter an, die Git lesen und schreiben wird. Kann -1, 0, 1 oder 2 sein. Beachten Sie, dass Werte größer als 1 mit älteren Git-Versionen, die diese Versionen noch nicht verstehen, möglicherweise nicht kompatibel sind. Seien Sie vorsichtig, wenn Sie in einer Umgebung mit gemischten Versionen arbeiten.

Standardmäßig -1.

Wenn -1, verwendet Git die Version der geänderten Pfad-Bloom-Filter im Repository und standardmäßig 1, wenn keine vorhanden sind.

Wenn 0, liest Git keine Bloom-Filter und schreibt Version 1 Bloom-Filter, wenn zum Schreiben aufgefordert wird.

Wenn 1, liest Git nur Version 1 Bloom-Filter und schreibt Version 1 Bloom-Filter.

Wenn 2, liest Git nur Version 2 Bloom-Filter und schreibt Version 2 Bloom-Filter.

Weitere Informationen finden Sie unter git-commit-graph[1].

DATEIFORM

Siehe gitformat-commit-graph[5].

GIT

Teil der git[1] Suite