]>
Commit | Line | Data |
---|---|---|
48a8c26c | 1 | Git pack format |
9760662f JH |
2 | =============== |
3 | ||
17420eaf | 4 | == Checksums and object IDs |
5 | ||
6 | In a repository using the traditional SHA-1, pack checksums, index checksums, | |
7 | and object IDs (object names) mentioned below are all computed using SHA-1. | |
8 | Similarly, in SHA-256 repositories, these values are computed using SHA-256. | |
9 | ||
5316c8e9 | 10 | == pack-*.pack files have the following format: |
9760662f | 11 | |
71362bd5 | 12 | - A header appears at the beginning and consists of the following: |
9760662f | 13 | |
1361fa3e SP |
14 | 4-byte signature: |
15 | The signature is: {'P', 'A', 'C', 'K'} | |
16 | ||
17 | 4-byte version number (network byte order): | |
48a8c26c | 18 | Git currently accepts version number 2 or 3 but |
1361fa3e SP |
19 | generates version 2 only. |
20 | ||
9760662f JH |
21 | 4-byte number of objects contained in the pack (network byte order) |
22 | ||
23 | Observation: we cannot have more than 4G versions ;-) and | |
24 | more than 4G objects in a pack. | |
25 | ||
26 | - The header is followed by number of object entries, each of | |
27 | which looks like this: | |
28 | ||
29 | (undeltified representation) | |
979ea585 | 30 | n-byte type and length (3-bit type, (n-1)*7+4-bit length) |
9760662f JH |
31 | compressed data |
32 | ||
33 | (deltified representation) | |
979ea585 | 34 | n-byte type and length (3-bit type, (n-1)*7+4-bit length) |
17420eaf | 35 | base object name if OBJ_REF_DELTA or a negative relative |
06cb843f SS |
36 | offset from the delta object's position in the pack if this |
37 | is an OBJ_OFS_DELTA object | |
9760662f JH |
38 | compressed delta data |
39 | ||
40 | Observation: length of each object is encoded in a variable | |
41 | length format and is not constrained to 32-bit or anything. | |
42 | ||
17420eaf | 43 | - The trailer records a pack checksum of all of the above. |
9760662f | 44 | |
011b6486 NTND |
45 | === Object types |
46 | ||
47 | Valid object types are: | |
48 | ||
49 | - OBJ_COMMIT (1) | |
50 | - OBJ_TREE (2) | |
51 | - OBJ_BLOB (3) | |
52 | - OBJ_TAG (4) | |
53 | - OBJ_OFS_DELTA (6) | |
54 | - OBJ_REF_DELTA (7) | |
55 | ||
56 | Type 5 is reserved for future expansion. Type 0 is invalid. | |
57 | ||
58 | === Deltified representation | |
59 | ||
60 | Conceptually there are only four object types: commit, tree, tag and | |
61 | blob. However to save space, an object could be stored as a "delta" of | |
62 | another "base" object. These representations are assigned new types | |
63 | ofs-delta and ref-delta, which is only valid in a pack file. | |
64 | ||
65 | Both ofs-delta and ref-delta store the "delta" to be applied to | |
66 | another object (called 'base object') to reconstruct the object. The | |
17420eaf | 67 | difference between them is, ref-delta directly encodes base object |
68 | name. If the base object is in the same pack, ofs-delta encodes | |
011b6486 NTND |
69 | the offset of the base object in the pack instead. |
70 | ||
71 | The base object could also be deltified if it's in the same pack. | |
72 | Ref-delta can also refer to an object outside the pack (i.e. the | |
73 | so-called "thin pack"). When stored on disk however, the pack should | |
74 | be self contained to avoid cyclic dependency. | |
75 | ||
76 | The delta data is a sequence of instructions to reconstruct an object | |
77 | from the base object. If the base object is deltified, it must be | |
78 | converted to canonical form first. Each instruction appends more and | |
79 | more data to the target object until it's complete. There are two | |
80 | supported instructions so far: one for copy a byte range from the | |
81 | source object and one for inserting new data embedded in the | |
82 | instruction itself. | |
83 | ||
84 | Each instruction has variable length. Instruction type is determined | |
85 | by the seventh bit of the first octet. The following diagrams follow | |
86 | the convention in RFC 1951 (Deflate compressed data format). | |
87 | ||
88 | ==== Instruction to copy from base object | |
89 | ||
90 | +----------+---------+---------+---------+---------+-------+-------+-------+ | |
91 | | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 | | |
92 | +----------+---------+---------+---------+---------+-------+-------+-------+ | |
93 | ||
94 | This is the instruction format to copy a byte range from the source | |
95 | object. It encodes the offset to copy from and the number of bytes to | |
96 | copy. Offset and size are in little-endian order. | |
97 | ||
98 | All offset and size bytes are optional. This is to reduce the | |
99 | instruction size when encoding small offsets or sizes. The first seven | |
100 | bits in the first octet determines which of the next seven octets is | |
101 | present. If bit zero is set, offset1 is present. If bit one is set | |
102 | offset2 is present and so on. | |
103 | ||
104 | Note that a more compact instruction does not change offset and size | |
105 | encoding. For example, if only offset2 is omitted like below, offset3 | |
106 | still contains bits 16-23. It does not become offset2 and contains | |
107 | bits 8-15 even if it's right next to offset1. | |
108 | ||
109 | +----------+---------+---------+ | |
110 | | 10000101 | offset1 | offset3 | | |
111 | +----------+---------+---------+ | |
112 | ||
113 | In its most compact form, this instruction only takes up one byte | |
114 | (0x80) with both offset and size omitted, which will have default | |
115 | values zero. There is another exception: size zero is automatically | |
116 | converted to 0x10000. | |
117 | ||
118 | ==== Instruction to add new data | |
119 | ||
120 | +----------+============+ | |
121 | | 0xxxxxxx | data | | |
122 | +----------+============+ | |
123 | ||
124 | This is the instruction to construct target object without the base | |
125 | object. The following data is appended to the target object. The first | |
126 | seven bits of the first octet determines the size of data in | |
127 | bytes. The size must be non-zero. | |
128 | ||
129 | ==== Reserved instruction | |
130 | ||
131 | +----------+============ | |
132 | | 00000000 | | |
133 | +----------+============ | |
134 | ||
135 | This is the instruction reserved for future expansion. | |
136 | ||
5316c8e9 | 137 | == Original (version 1) pack-*.idx files have the following format: |
9760662f JH |
138 | |
139 | - The header consists of 256 4-byte network byte order | |
140 | integers. N-th entry of this table records the number of | |
141 | objects in the corresponding pack, the first byte of whose | |
71362bd5 | 142 | object name is less than or equal to N. This is called the |
9760662f JH |
143 | 'first-level fan-out' table. |
144 | ||
1361fa3e | 145 | - The header is followed by sorted 24-byte entries, one entry |
9760662f JH |
146 | per object in the pack. Each entry is: |
147 | ||
148 | 4-byte network byte order integer, recording where the | |
149 | object is stored in the packfile as the offset from the | |
150 | beginning. | |
151 | ||
17420eaf | 152 | one object name of the appropriate size. |
9760662f | 153 | |
9760662f JH |
154 | - The file is concluded with a trailer: |
155 | ||
17420eaf | 156 | A copy of the pack checksum at the end of the corresponding |
157 | packfile. | |
9760662f | 158 | |
17420eaf | 159 | Index checksum of all of the above. |
9760662f JH |
160 | |
161 | Pack Idx file: | |
162 | ||
71362bd5 | 163 | -- +--------------------------------+ |
164 | fanout | fanout[0] = 2 (for example) |-. | |
165 | table +--------------------------------+ | | |
9760662f JH |
166 | | fanout[1] | | |
167 | +--------------------------------+ | | |
168 | | fanout[2] | | | |
169 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | |
71362bd5 | 170 | | fanout[255] = total objects |---. |
171 | -- +--------------------------------+ | | | |
172 | main | offset | | | | |
173 | index | object name 00XXXXXXXXXXXXXXXX | | | | |
174 | table +--------------------------------+ | | | |
175 | | offset | | | | |
176 | | object name 00XXXXXXXXXXXXXXXX | | | | |
177 | +--------------------------------+<+ | | |
178 | .-| offset | | | |
179 | | | object name 01XXXXXXXXXXXXXXXX | | | |
180 | | +--------------------------------+ | | |
181 | | | offset | | | |
182 | | | object name 01XXXXXXXXXXXXXXXX | | | |
183 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | |
184 | | | offset | | | |
185 | | | object name FFXXXXXXXXXXXXXXXX | | | |
186 | --| +--------------------------------+<--+ | |
9760662f JH |
187 | trailer | | packfile checksum | |
188 | | +--------------------------------+ | |
189 | | | idxfile checksum | | |
190 | | +--------------------------------+ | |
a6080a0a | 191 | .-------. |
9760662f JH |
192 | | |
193 | Pack file entry: <+ | |
194 | ||
195 | packed object header: | |
979ea585 PE |
196 | 1-byte size extension bit (MSB) |
197 | type (next 3 bit) | |
a6080a0a | 198 | size0 (lower 4-bit) |
9760662f JH |
199 | n-byte sizeN (as long as MSB is set, each 7-bit) |
200 | size0..sizeN form 4+7+7+..+7 bit integer, size0 | |
979ea585 PE |
201 | is the least significant part, and sizeN is the |
202 | most significant part. | |
9760662f JH |
203 | packed object data: |
204 | If it is not DELTA, then deflated bytes (the size above | |
205 | is the size before compression). | |
9de328fe | 206 | If it is REF_DELTA, then |
17420eaf | 207 | base object name (the size above is the |
a6080a0a | 208 | size of the delta data that follows). |
9760662f | 209 | delta data, deflated. |
9de328fe PE |
210 | If it is OFS_DELTA, then |
211 | n-byte offset (see below) interpreted as a negative | |
212 | offset from the type-byte of the header of the | |
213 | ofs-delta entry (the size above is the size of | |
214 | the delta data that follows). | |
215 | delta data, deflated. | |
216 | ||
217 | offset encoding: | |
218 | n bytes with MSB set in all but the last one. | |
219 | The offset is then the number constructed by | |
220 | concatenating the lower 7 bit of each byte, and | |
221 | for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1)) | |
222 | to the result. | |
223 | ||
71362bd5 | 224 | |
225 | ||
5316c8e9 TA |
226 | == Version 2 pack-*.idx files support packs larger than 4 GiB, and |
227 | have some other reorganizations. They have the format: | |
71362bd5 | 228 | |
229 | - A 4-byte magic number '\377tOc' which is an unreasonable | |
230 | fanout[0] value. | |
231 | ||
232 | - A 4-byte version number (= 2) | |
233 | ||
234 | - A 256-entry fan-out table just like v1. | |
235 | ||
17420eaf | 236 | - A table of sorted object names. These are packed together |
237 | without offset values to reduce the cache footprint of the | |
238 | binary search for a specific object name. | |
71362bd5 | 239 | |
240 | - A table of 4-byte CRC32 values of the packed object data. | |
241 | This is new in v2 so compressed data can be copied directly | |
f1cdcc70 | 242 | from pack to pack during repacking without undetected |
71362bd5 | 243 | data corruption. |
244 | ||
245 | - A table of 4-byte offset values (in network byte order). | |
246 | These are usually 31-bit pack file offsets, but large | |
247 | offsets are encoded as an index into the next table with | |
248 | the msbit set. | |
249 | ||
250 | - A table of 8-byte offset entries (empty for pack files less | |
251 | than 2 GiB). Pack files are organized with heavily used | |
252 | objects toward the front, so most object references should | |
253 | not need to refer to this table. | |
254 | ||
255 | - The same trailer as a v1 pack file: | |
256 | ||
17420eaf | 257 | A copy of the pack checksum at the end of |
71362bd5 | 258 | corresponding packfile. |
259 | ||
17420eaf | 260 | Index checksum of all of the above. |
e0d1bcf8 DS |
261 | |
262 | == multi-pack-index (MIDX) files have the following format: | |
263 | ||
264 | The multi-pack-index files refer to multiple pack-files and loose objects. | |
265 | ||
266 | In order to allow extensions that add extra data to the MIDX, we organize | |
267 | the body into "chunks" and provide a lookup table at the beginning of the | |
268 | body. The header includes certain length values, such as the number of packs, | |
269 | the number of base MIDX files, hash lengths and types. | |
270 | ||
271 | All 4-byte numbers are in network order. | |
272 | ||
273 | HEADER: | |
274 | ||
275 | 4-byte signature: | |
276 | The signature is: {'M', 'I', 'D', 'X'} | |
277 | ||
278 | 1-byte version number: | |
279 | Git only writes or recognizes version 1. | |
280 | ||
281 | 1-byte Object Id Version | |
d9607542 DS |
282 | We infer the length of object IDs (OIDs) from this value: |
283 | 1 => SHA-1 | |
284 | 2 => SHA-256 | |
285 | If the hash type does not match the repository's hash algorithm, | |
286 | the multi-pack-index file should be ignored with a warning | |
287 | presented to the user. | |
e0d1bcf8 DS |
288 | |
289 | 1-byte number of "chunks" | |
290 | ||
291 | 1-byte number of base multi-pack-index files: | |
292 | This value is currently always zero. | |
293 | ||
294 | 4-byte number of pack files | |
295 | ||
296 | CHUNK LOOKUP: | |
297 | ||
298 | (C + 1) * 12 bytes providing the chunk offsets: | |
299 | First 4 bytes describe chunk id. Value 0 is a terminating label. | |
300 | Other 8 bytes provide offset in current file for chunk to start. | |
301 | (Chunks are provided in file-order, so you can infer the length | |
302 | using the next chunk position if necessary.) | |
303 | ||
304 | The remaining data in the body is described one chunk at a time, and | |
305 | these chunks may be given in any order. Chunks are required unless | |
306 | otherwise specified. | |
307 | ||
308 | CHUNK DATA: | |
309 | ||
32f3c541 DS |
310 | Packfile Names (ID: {'P', 'N', 'A', 'M'}) |
311 | Stores the packfile names as concatenated, null-terminated strings. | |
312 | Packfiles must be listed in lexicographic order for fast lookups by | |
313 | name. This is the only chunk not guaranteed to be a multiple of four | |
314 | bytes in length, so should be the last chunk for alignment reasons. | |
315 | ||
d7cacf29 DS |
316 | OID Fanout (ID: {'O', 'I', 'D', 'F'}) |
317 | The ith entry, F[i], stores the number of OIDs with first | |
318 | byte at most i. Thus F[255] stores the total | |
319 | number of objects. | |
320 | ||
0d5b3a5e DS |
321 | OID Lookup (ID: {'O', 'I', 'D', 'L'}) |
322 | The OIDs for all objects in the MIDX are stored in lexicographic | |
323 | order in this chunk. | |
324 | ||
662148c4 DS |
325 | Object Offsets (ID: {'O', 'O', 'F', 'F'}) |
326 | Stores two 4-byte values for every object. | |
327 | 1: The pack-int-id for the pack storing this object. | |
328 | 2: The offset within the pack. | |
eb31044f | 329 | If all offsets are less than 2^32, then the large offset chunk |
662148c4 DS |
330 | will not exist and offsets are stored as in IDX v1. |
331 | If there is at least one offset value larger than 2^32-1, then | |
eb31044f JB |
332 | the large offset chunk must exist, and offsets larger than |
333 | 2^31-1 must be stored in it instead. If the large offset chunk | |
662148c4 DS |
334 | exists and the 31st bit is on, then removing that bit reveals |
335 | the row in the large offsets containing the 8-byte offset of | |
336 | this object. | |
337 | ||
338 | [Optional] Object Large Offsets (ID: {'L', 'O', 'F', 'F'}) | |
339 | 8-byte offsets into large packfiles. | |
e0d1bcf8 DS |
340 | |
341 | TRAILER: | |
342 | ||
17420eaf | 343 | Index checksum of the above contents. |