1
- Git commit graph format
2
- =======================
1
+ gitformat-commit-graph(5)
2
+ =========================
3
+
4
+ NAME
5
+ ----
6
+ gitformat-commit-graph - Git commit graph format
7
+
8
+ SYNOPSIS
9
+ --------
10
+ [verse]
11
+ $GIT_DIR/objects/info/commit-graph
12
+ $GIT_DIR/objects/info/commit-graphs/*
13
+
14
+ DESCRIPTION
15
+ -----------
3
16
4
17
The Git commit graph stores a list of commit OIDs and some associated
5
18
metadata, including:
@@ -30,7 +43,7 @@ and hash type.
30
43
31
44
All multi-byte numbers are in network byte order.
32
45
33
- HEADER:
46
+ === HEADER:
34
47
35
48
4-byte signature:
36
49
The signature is: {'C', 'G', 'P', 'H'}
@@ -52,7 +65,7 @@ HEADER:
52
65
We infer the length (H*B) of the Base Graphs chunk
53
66
from this value.
54
67
55
- CHUNK LOOKUP:
68
+ === CHUNK LOOKUP:
56
69
57
70
(C + 1) * 12 bytes listing the table of contents for the chunks:
58
71
First 4 bytes describe the chunk id. Value 0 is a terminating label.
@@ -68,17 +81,17 @@ CHUNK LOOKUP:
68
81
these chunks may be given in any order. Chunks are required unless
69
82
otherwise specified.
70
83
71
- CHUNK DATA:
84
+ === CHUNK DATA:
72
85
73
- OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes)
86
+ ==== OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes)
74
87
The ith entry, F[i], stores the number of OIDs with first
75
88
byte at most i. Thus F[255] stores the total
76
89
number of commits (N).
77
90
78
- OID Lookup (ID: {'O', 'I', 'D', 'L'}) (N * H bytes)
91
+ ==== OID Lookup (ID: {'O', 'I', 'D', 'L'}) (N * H bytes)
79
92
The OIDs for all commits in the graph, sorted in ascending order.
80
93
81
- Commit Data (ID: {'C', 'D', 'A', 'T' }) (N * (H + 16) bytes)
94
+ ==== Commit Data (ID: {'C', 'D', 'A', 'T' }) (N * (H + 16) bytes)
82
95
* The first H bytes are for the OID of the root tree.
83
96
* The next 8 bytes are for the positions of the first two parents
84
97
of the ith commit. Stores value 0x70000000 if no parent in that
@@ -93,7 +106,7 @@ CHUNK DATA:
93
106
2 bits of the lowest byte, storing the 33rd and 34th bit of the
94
107
commit time.
95
108
96
- Generation Data (ID: {'G', 'D', 'A', '2' }) (N * 4 bytes) [Optional]
109
+ ==== Generation Data (ID: {'G', 'D', 'A', '2' }) (N * 4 bytes) [Optional]
97
110
* This list of 4-byte values store corrected commit date offsets for the
98
111
commits, arranged in the same order as commit data chunk.
99
112
* If the corrected commit date offset cannot be stored within 31 bits,
@@ -104,30 +117,30 @@ CHUNK DATA:
104
117
by compatible versions of Git and in case of split commit-graph chains,
105
118
the topmost layer also has Generation Data chunk.
106
119
107
- Generation Data Overflow (ID: {'G', 'D', 'O', '2' }) [Optional]
120
+ ==== Generation Data Overflow (ID: {'G', 'D', 'O', '2' }) [Optional]
108
121
* This list of 8-byte values stores the corrected commit date offsets
109
122
for commits with corrected commit date offsets that cannot be
110
123
stored within 31 bits.
111
124
* Generation Data Overflow chunk is present only when Generation Data
112
125
chunk is present and atleast one corrected commit date offset cannot
113
126
be stored within 31 bits.
114
127
115
- Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional]
128
+ ==== Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional]
116
129
This list of 4-byte values store the second through nth parents for
117
130
all octopus merges. The second parent value in the commit data stores
118
131
an array position within this list along with the most-significant bit
119
132
on. Starting at that array position, iterate through this list of commit
120
133
positions for the parents until reaching a value with the most-significant
121
134
bit on. The other bits correspond to the position of the last parent.
122
135
123
- Bloom Filter Index (ID: {'B', 'I', 'D', 'X'}) (N * 4 bytes) [Optional]
136
+ ==== Bloom Filter Index (ID: {'B', 'I', 'D', 'X'}) (N * 4 bytes) [Optional]
124
137
* The ith entry, BIDX[i], stores the number of bytes in all Bloom filters
125
138
from commit 0 to commit i (inclusive) in lexicographic order. The Bloom
126
139
filter for the i-th commit spans from BIDX[i-1] to BIDX[i] (plus header
127
140
length), where BIDX[-1] is 0.
128
141
* The BIDX chunk is ignored if the BDAT chunk is not present.
129
142
130
- Bloom Filter Data (ID: {'B', 'D', 'A', 'T'}) [Optional]
143
+ ==== Bloom Filter Data (ID: {'B', 'D', 'A', 'T'}) [Optional]
131
144
* It starts with header consisting of three unsigned 32-bit integers:
132
145
- Version of the hash algorithm being used. We currently only support
133
146
value 1 which corresponds to the 32-bit version of the murmur3 hash
@@ -147,13 +160,13 @@ CHUNK DATA:
147
160
of length one, with either all bits set to zero or one respectively.
148
161
* The BDAT chunk is present if and only if BIDX is present.
149
162
150
- Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional]
163
+ ==== Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional]
151
164
This list of H-byte hashes describe a set of B commit-graph files that
152
165
form a commit-graph chain. The graph position for the ith commit in this
153
166
file's OID Lookup chunk is equal to i plus the number of commits in all
154
167
base graphs. If B is non-zero, this chunk must exist.
155
168
156
- TRAILER:
169
+ === TRAILER:
157
170
158
171
H-byte HASH-checksum of all of the above.
159
172
@@ -164,3 +177,7 @@ the number '2' in their chunk IDs because a previous version of Git wrote
164
177
possibly erroneous data in these chunks with the IDs "GDAT" and "GDOV". By
165
178
changing the IDs, newer versions of Git will silently ignore those older
166
179
chunks and write the new information without trusting the incorrect data.
180
+
181
+ GIT
182
+ ---
183
+ Part of the linkgit:git[1] suite
0 commit comments