Einrichtung und Konfiguration
Projekte holen und erstellen
Grundlegende Snapshots
Branching und Merging
Projekte teilen und aktualisieren
Inspektion und Vergleich
Patching
Debugging
Externe Systeme
Server-Administration
Anleitungen
- gitattributes
- Konventionen der Kommandozeile
- Tägliches Git
- Häufig gestellte Fragen (FAQ)
- Glossar
- Hooks
- gitignore
- gitmodules
- Revisionen
- Submodule
- Tutorial
- Workflows
- Alle Anleitungen...
Administration
Plumbing-Befehle
- 2.47.1 → 2.52.0 keine Änderungen
-
2.47.0
2024-10-06
- 2.46.1 → 2.46.4 keine Änderungen
-
2.46.0
2024-07-29
- 2.39.1 → 2.45.4 keine Änderungen
-
2.39.0
2022-12-12
- 2.38.1 → 2.38.5 keine Änderungen
-
2.38.0
2022-10-02
BESCHREIBUNG
Der Git-Commit-Graph speichert eine Liste von Commit-OIDs und zugehörige Metadaten, darunter:
-
Die Generationsnummer des Commits.
-
Die Root-Tree-OID.
-
Das Commit-Datum.
-
Die Eltern des Commits, gespeichert durch Positionsreferenzen innerhalb der Graphdatei.
-
Der Bloom-Filter des Commits, der die zwischen dem Commit und seinem ersten Elternteil geänderten Pfade enthält, falls angefordert.
Diese Positionsreferenzen werden als vorzeichenlose 32-Bit-Ganzzahlen gespeichert, die der Array-Position in der Liste der Commit-OIDs entsprechen. Aufgrund einiger spezieller Konstanten, die wir zur Verfolgung von Eltern verwenden, können wir maximal (1 << 30) + (1 << 29) + (1 << 28) - 1 (etwa 1,8 Milliarden) Commits speichern.
Commit-Graph-Dateien haben das folgende Format
Um Erweiterungen zu ermöglichen, die zusätzliche Daten zum Graphen hinzufügen, organisieren wir den Körper in "Chunks" und stellen am Anfang des Körpers eine binäre Nachschlagetabelle bereit. Der Header enthält bestimmte Werte, wie z. B. die Anzahl der Chunks und den Hash-Typ.
Alle Mehrbyte-Zahlen sind in Netzwerk-Byte-Reihenfolge.
HEADER
4-byte signature:
The signature is: {'C', 'G', 'P', 'H'}
1-byte version number:
Currently, the only valid version is 1.
1-byte Hash Version
We infer the hash length (H) from this value:
1 => SHA-1
2 => SHA-256
If the hash type does not match the repository's hash algorithm, the
commit-graph file should be ignored with a warning presented to the
user.
1-byte number (C) of "chunks"
1-byte number (B) of base commit-graphs
We infer the length (H*B) of the Base Graphs chunk
from this value.
CHUNK LOOKUP
(C + 1) * 12 bytes listing the table of contents for the chunks:
First 4 bytes describe the chunk id. Value 0 is a terminating label.
Other 8 bytes provide the byte-offset in current file for chunk to
start. (Chunks are ordered contiguously in the file, so you can infer
the length using the next chunk position if necessary.) Each chunk
ID appears at most once.
The CHUNK LOOKUP matches the table of contents from the chunk-based file format, see gitformat-chunk[5]
The remaining data in the body is described one chunk at a time, and these chunks may be given in any order. Chunks are required unless otherwise specified.
CHUNK DATA
OID Fanout (ID: {O, I, D, F}) (256 * 4 Bytes)
The ith entry, F[i], stores the number of OIDs with first byte at most i. Thus F[255] stores the total number of commits (N).
OID Lookup (ID: {O, I, D, L}) (N * H Bytes)
The OIDs for all commits in the graph, sorted in ascending order.
Commit Data (ID: {C, D, A, T }) (N * (H + 16) Bytes)
-
Die ersten H Bytes sind für die OID des Root-Trees.
-
Die nächsten 8 Bytes sind für die Positionen der ersten beiden Eltern des i-ten Commits. Speichert den Wert 0x70000000, wenn keine Eltern in dieser Position vorhanden sind. Wenn mehr als zwei Eltern vorhanden sind, hat der zweite Wert das höchstwertige Bit gesetzt, und die anderen Bits speichern eine Array-Position in den Extra Edge List Chunk.
-
Die nächsten 8 Bytes speichern die Topologie-Ebene (Generationsnummer v1) des Commits und die Commit-Zeit in Sekunden seit EPOCH. Die Generationsnummer verwendet die oberen 30 Bits der ersten 4 Bytes, während die Commit-Zeit die 32 Bits der zweiten 4 Bytes verwendet, zusammen mit den niedrigsten 2 Bits des niedrigsten Bytes, wobei die 33. und 34. Bit der Commit-Zeit gespeichert werden.
Generation Data (ID: {G, D, A, 2 }) (N * 4 Bytes) [Optional]
-
Diese Liste von 4-Byte-Werten speichert korrigierte Commit-Datums-Offsets für die Commits, angeordnet in derselben Reihenfolge wie der Commit-Data-Chunk.
-
Wenn der korrigierte Commit-Datums-Offset nicht innerhalb von 31 Bits gespeichert werden kann, hat der Wert sein höchstwertiges Bit gesetzt und die anderen Bits speichern die Position des korrigierten Commit-Datums im Generation Data Overflow Chunk.
-
Der Generation Data Chunk ist nur vorhanden, wenn die Commit-Graph-Datei von kompatiblen Versionen von Git geschrieben wurde und im Falle von geteilten Commit-Graph-Ketten hat auch die oberste Ebene einen Generation Data Chunk.
Generation Data Overflow (ID: {G, D, O, 2 }) [Optional]
-
Diese Liste von 8-Byte-Werten speichert die korrigierten Commit-Datums-Offsets für Commits mit korrigierten Commit-Datums-Offsets, die nicht innerhalb von 31 Bits gespeichert werden können.
-
Der Generation Data Overflow Chunk ist nur vorhanden, wenn der Generation Data Chunk vorhanden ist und mindestens ein korrigierter Commit-Datums-Offset nicht innerhalb von 31 Bits gespeichert werden kann.
Extra Edge List (ID: {E, D, G, E}) [Optional]
This list of 4-byte values store the second through nth parents for all octopus merges. The second parent value in the commit data stores an array position within this list along with the most-significant bit on. Starting at that array position, iterate through this list of commit positions for the parents until reaching a value with the most-significant bit on. The other bits correspond to the position of the last parent.
Bloom Filter Index (ID: {B, I, D, X}) (N * 4 Bytes) [Optional]
-
Der i-te Eintrag, BIDX[i], speichert die Anzahl der Bytes in allen Bloom-Filtern von Commit 0 bis Commit i (einschließlich) in lexikographischer Reihenfolge. Der Bloom-Filter für den i-ten Commit erstreckt sich von BIDX[i-1] bis BIDX[i] (plus Header-Länge), wobei BIDX[-1] gleich 0 ist.
-
Der BIDX-Chunk wird ignoriert, wenn der BDAT-Chunk nicht vorhanden ist.
Bloom Filter Data (ID: {B, D, A, T}) [Optional]
-
Er beginnt mit einem Header, der aus drei vorzeichenlosen 32-Bit-Ganzzahlen besteht.
-
Version des verwendeten Hash-Algorithmus. Wir unterstützen derzeit den Wert 2, der der 32-Bit-Version von murmur3 entspricht, die genau wie in https://en.wikipedia.org/wiki/MurmurHash#Algorithm beschrieben implementiert ist, und der doppelten Hashing-Technik mit den Seed-Werten 0x293ae76f und 0x7e646e2, wie in https://doi.org/10.1007/978-3-540-30494-4_26 "Bloom Filters in Probabilistic Verification" beschrieben. Version 1 Bloom-Filter haben einen Fehler, der auftritt, wenn `char` signed ist und das Repository Pfadnamen hat, die Zeichen >= 0x80 enthalten; Git unterstützt das Lesen und Schreiben dieser Filter, aber diese Fähigkeit wird in einer zukünftigen Version von Git entfernt.
-
Die Anzahl der Male, die ein Pfad gehasht wird, und somit die Anzahl der Bitpositionen, die kumulativ bestimmen, ob eine Datei im Commit vorhanden ist.
-
Die minimale Anzahl von Bits *b* pro Eintrag im Bloom-Filter. Wenn der Filter *n* Einträge enthält, dann ist die Filtergröße die minimale Anzahl von 64-Bit-Wörtern, die n*b Bits enthalten.
-
-
Der Rest des Chunks ist die Verkettung aller berechneten Bloom-Filter für die Commits in lexikographischer Reihenfolge.
-
Hinweis: Commits ohne Änderungen oder mit mehr als 512 Änderungen haben Bloom-Filter der Länge eins, mit entweder allen Bits auf Null oder Eins gesetzt, entsprechend.
-
Der BDAT-Chunk ist vorhanden, wenn und nur wenn BIDX vorhanden ist.
Base Graphs List (ID: {B, A, S, E}) [Optional]
This list of H-byte hashes describe a set of B commit-graph files that form a commit-graph chain. The graph position for the ith commit in this file's OID Lookup chunk is equal to i plus the number of commits in all base graphs. If B is non-zero, this chunk must exist.
Historische Anmerkungen
Die Chunks Generation Data (GDA2) und Generation Data Overflow (GDO2) haben die Nummer *2* in ihren Chunk-IDs, da eine frühere Version von Git möglicherweise fehlerhafte Daten in diesen Chunks mit den IDs "GDAT" und "GDOV" schrieb. Durch die Änderung der IDs werden neuere Versionen von Git diese älteren Chunks stillschweigend ignorieren und die neuen Informationen schreiben, ohne den falschen Daten zu vertrauen.
GIT
Teil der git[1] Suite