| Git pack format |
| =============== |
| |
| == Checksums and object IDs |
| |
| In a repository using the traditional SHA-1, pack checksums, index checksums, |
| and object IDs (object names) mentioned below are all computed using SHA-1. |
| Similarly, in SHA-256 repositories, these values are computed using SHA-256. |
| |
| == pack-*.pack files have the following format: |
| |
| - A header appears at the beginning and consists of the following: |
| |
| 4-byte signature: |
| The signature is: {'P', 'A', 'C', 'K'} |
| |
| 4-byte version number (network byte order): |
| Git currently accepts version number 2 or 3 but |
| generates version 2 only. |
| |
| 4-byte number of objects contained in the pack (network byte order) |
| |
| Observation: we cannot have more than 4G versions ;-) and |
| more than 4G objects in a pack. |
| |
| - The header is followed by number of object entries, each of |
| which looks like this: |
| |
| (undeltified representation) |
| n-byte type and length (3-bit type, (n-1)*7+4-bit length) |
| compressed data |
| |
| (deltified representation) |
| n-byte type and length (3-bit type, (n-1)*7+4-bit length) |
| base object name if OBJ_REF_DELTA or a negative relative |
| offset from the delta object's position in the pack if this |
| is an OBJ_OFS_DELTA object |
| compressed delta data |
| |
| Observation: length of each object is encoded in a variable |
| length format and is not constrained to 32-bit or anything. |
| |
| - The trailer records a pack checksum of all of the above. |
| |
| === Object types |
| |
| Valid object types are: |
| |
| - OBJ_COMMIT (1) |
| - OBJ_TREE (2) |
| - OBJ_BLOB (3) |
| - OBJ_TAG (4) |
| - OBJ_OFS_DELTA (6) |
| - OBJ_REF_DELTA (7) |
| |
| Type 5 is reserved for future expansion. Type 0 is invalid. |
| |
| === Size encoding |
| |
| This document uses the following "size encoding" of non-negative |
| integers: From each byte, the seven least significant bits are |
| used to form the resulting integer. As long as the most significant |
| bit is 1, this process continues; the byte with MSB 0 provides the |
| last seven bits. The seven-bit chunks are concatenated. Later |
| values are more significant. |
| |
| This size encoding should not be confused with the "offset encoding", |
| which is also used in this document. |
| |
| === Deltified representation |
| |
| Conceptually there are only four object types: commit, tree, tag and |
| blob. However to save space, an object could be stored as a "delta" of |
| another "base" object. These representations are assigned new types |
| ofs-delta and ref-delta, which is only valid in a pack file. |
| |
| Both ofs-delta and ref-delta store the "delta" to be applied to |
| another object (called 'base object') to reconstruct the object. The |
| difference between them is, ref-delta directly encodes base object |
| name. If the base object is in the same pack, ofs-delta encodes |
| the offset of the base object in the pack instead. |
| |
| The base object could also be deltified if it's in the same pack. |
| Ref-delta can also refer to an object outside the pack (i.e. the |
| so-called "thin pack"). When stored on disk however, the pack should |
| be self contained to avoid cyclic dependency. |
| |
| The delta data starts with the size of the base object and the |
| size of the object to be reconstructed. These sizes are |
| encoded using the size encoding from above. The remainder of |
| the delta data is a sequence of instructions to reconstruct the object |
| from the base object. If the base object is deltified, it must be |
| converted to canonical form first. Each instruction appends more and |
| more data to the target object until it's complete. There are two |
| supported instructions so far: one for copy a byte range from the |
| source object and one for inserting new data embedded in the |
| instruction itself. |
| |
| Each instruction has variable length. Instruction type is determined |
| by the seventh bit of the first octet. The following diagrams follow |
| the convention in RFC 1951 (Deflate compressed data format). |
| |
| ==== Instruction to copy from base object |
| |
| +----------+---------+---------+---------+---------+-------+-------+-------+ |
| | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 | |
| +----------+---------+---------+---------+---------+-------+-------+-------+ |
| |
| This is the instruction format to copy a byte range from the source |
| object. It encodes the offset to copy from and the number of bytes to |
| copy. Offset and size are in little-endian order. |
| |
| All offset and size bytes are optional. This is to reduce the |
| instruction size when encoding small offsets or sizes. The first seven |
| bits in the first octet determines which of the next seven octets is |
| present. If bit zero is set, offset1 is present. If bit one is set |
| offset2 is present and so on. |
| |
| Note that a more compact instruction does not change offset and size |
| encoding. For example, if only offset2 is omitted like below, offset3 |
| still contains bits 16-23. It does not become offset2 and contains |
| bits 8-15 even if it's right next to offset1. |
| |
| +----------+---------+---------+ |
| | 10000101 | offset1 | offset3 | |
| +----------+---------+---------+ |
| |
| In its most compact form, this instruction only takes up one byte |
| (0x80) with both offset and size omitted, which will have default |
| values zero. There is another exception: size zero is automatically |
| converted to 0x10000. |
| |
| ==== Instruction to add new data |
| |
| +----------+============+ |
| | 0xxxxxxx | data | |
| +----------+============+ |
| |
| This is the instruction to construct target object without the base |
| object. The following data is appended to the target object. The first |
| seven bits of the first octet determines the size of data in |
| bytes. The size must be non-zero. |
| |
| ==== Reserved instruction |
| |
| +----------+============ |
| | 00000000 | |
| +----------+============ |
| |
| This is the instruction reserved for future expansion. |
| |
| == Original (version 1) pack-*.idx files have the following format: |
| |
| - The header consists of 256 4-byte network byte order |
| integers. N-th entry of this table records the number of |
| objects in the corresponding pack, the first byte of whose |
| object name is less than or equal to N. This is called the |
| 'first-level fan-out' table. |
| |
| - The header is followed by sorted 24-byte entries, one entry |
| per object in the pack. Each entry is: |
| |
| 4-byte network byte order integer, recording where the |
| object is stored in the packfile as the offset from the |
| beginning. |
| |
| one object name of the appropriate size. |
| |
| - The file is concluded with a trailer: |
| |
| A copy of the pack checksum at the end of the corresponding |
| packfile. |
| |
| Index checksum of all of the above. |
| |
| Pack Idx file: |
| |
| -- +--------------------------------+ |
| fanout | fanout[0] = 2 (for example) |-. |
| table +--------------------------------+ | |
| | fanout[1] | | |
| +--------------------------------+ | |
| | fanout[2] | | |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| | fanout[255] = total objects |---. |
| -- +--------------------------------+ | | |
| main | offset | | | |
| index | object name 00XXXXXXXXXXXXXXXX | | | |
| table +--------------------------------+ | | |
| | offset | | | |
| | object name 00XXXXXXXXXXXXXXXX | | | |
| +--------------------------------+<+ | |
| .-| offset | | |
| | | object name 01XXXXXXXXXXXXXXXX | | |
| | +--------------------------------+ | |
| | | offset | | |
| | | object name 01XXXXXXXXXXXXXXXX | | |
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| | | offset | | |
| | | object name FFXXXXXXXXXXXXXXXX | | |
| --| +--------------------------------+<--+ |
| trailer | | packfile checksum | |
| | +--------------------------------+ |
| | | idxfile checksum | |
| | +--------------------------------+ |
| .-------. |
| | |
| Pack file entry: <+ |
| |
| packed object header: |
| 1-byte size extension bit (MSB) |
| type (next 3 bit) |
| size0 (lower 4-bit) |
| n-byte sizeN (as long as MSB is set, each 7-bit) |
| size0..sizeN form 4+7+7+..+7 bit integer, size0 |
| is the least significant part, and sizeN is the |
| most significant part. |
| packed object data: |
| If it is not DELTA, then deflated bytes (the size above |
| is the size before compression). |
| If it is REF_DELTA, then |
| base object name (the size above is the |
| size of the delta data that follows). |
| delta data, deflated. |
| If it is OFS_DELTA, then |
| n-byte offset (see below) interpreted as a negative |
| offset from the type-byte of the header of the |
| ofs-delta entry (the size above is the size of |
| the delta data that follows). |
| delta data, deflated. |
| |
| offset encoding: |
| n bytes with MSB set in all but the last one. |
| The offset is then the number constructed by |
| concatenating the lower 7 bit of each byte, and |
| for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1)) |
| to the result. |
| |
| |
| |
| == Version 2 pack-*.idx files support packs larger than 4 GiB, and |
| have some other reorganizations. They have the format: |
| |
| - A 4-byte magic number '\377tOc' which is an unreasonable |
| fanout[0] value. |
| |
| - A 4-byte version number (= 2) |
| |
| - A 256-entry fan-out table just like v1. |
| |
| - A table of sorted object names. These are packed together |
| without offset values to reduce the cache footprint of the |
| binary search for a specific object name. |
| |
| - A table of 4-byte CRC32 values of the packed object data. |
| This is new in v2 so compressed data can be copied directly |
| from pack to pack during repacking without undetected |
| data corruption. |
| |
| - A table of 4-byte offset values (in network byte order). |
| These are usually 31-bit pack file offsets, but large |
| offsets are encoded as an index into the next table with |
| the msbit set. |
| |
| - A table of 8-byte offset entries (empty for pack files less |
| than 2 GiB). Pack files are organized with heavily used |
| objects toward the front, so most object references should |
| not need to refer to this table. |
| |
| - The same trailer as a v1 pack file: |
| |
| A copy of the pack checksum at the end of |
| corresponding packfile. |
| |
| Index checksum of all of the above. |
| |
| == pack-*.rev files have the format: |
| |
| - A 4-byte magic number '0x52494458' ('RIDX'). |
| |
| - A 4-byte version identifier (= 1). |
| |
| - A 4-byte hash function identifier (= 1 for SHA-1, 2 for SHA-256). |
| |
| - A table of index positions (one per packed object, num_objects in |
| total, each a 4-byte unsigned integer in network order), sorted by |
| their corresponding offsets in the packfile. |
| |
| - A trailer, containing a: |
| |
| checksum of the corresponding packfile, and |
| |
| a checksum of all of the above. |
| |
| All 4-byte numbers are in network order. |
| |
| == multi-pack-index (MIDX) files have the following format: |
| |
| The multi-pack-index files refer to multiple pack-files and loose objects. |
| |
| In order to allow extensions that add extra data to the MIDX, we organize |
| the body into "chunks" and provide a lookup table at the beginning of the |
| body. The header includes certain length values, such as the number of packs, |
| the number of base MIDX files, hash lengths and types. |
| |
| All 4-byte numbers are in network order. |
| |
| HEADER: |
| |
| 4-byte signature: |
| The signature is: {'M', 'I', 'D', 'X'} |
| |
| 1-byte version number: |
| Git only writes or recognizes version 1. |
| |
| 1-byte Object Id Version |
| We infer the length of object IDs (OIDs) from this value: |
| 1 => SHA-1 |
| 2 => SHA-256 |
| If the hash type does not match the repository's hash algorithm, |
| the multi-pack-index file should be ignored with a warning |
| presented to the user. |
| |
| 1-byte number of "chunks" |
| |
| 1-byte number of base multi-pack-index files: |
| This value is currently always zero. |
| |
| 4-byte number of pack files |
| |
| CHUNK LOOKUP: |
| |
| (C + 1) * 12 bytes providing the chunk offsets: |
| First 4 bytes describe chunk id. Value 0 is a terminating label. |
| Other 8 bytes provide offset in current file for chunk to start. |
| (Chunks are provided in file-order, so you can infer the length |
| using the next chunk position if necessary.) |
| |
| The CHUNK LOOKUP matches the table of contents from |
| link:technical/chunk-format.html[the chunk-based file format]. |
| |
| 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: |
| |
| Packfile Names (ID: {'P', 'N', 'A', 'M'}) |
| Stores the packfile names as concatenated, null-terminated strings. |
| Packfiles must be listed in lexicographic order for fast lookups by |
| name. This is the only chunk not guaranteed to be a multiple of four |
| bytes in length, so should be the last chunk for alignment reasons. |
| |
| OID Fanout (ID: {'O', 'I', 'D', 'F'}) |
| The ith entry, F[i], stores the number of OIDs with first |
| byte at most i. Thus F[255] stores the total |
| number of objects. |
| |
| OID Lookup (ID: {'O', 'I', 'D', 'L'}) |
| The OIDs for all objects in the MIDX are stored in lexicographic |
| order in this chunk. |
| |
| Object Offsets (ID: {'O', 'O', 'F', 'F'}) |
| Stores two 4-byte values for every object. |
| 1: The pack-int-id for the pack storing this object. |
| 2: The offset within the pack. |
| If all offsets are less than 2^32, then the large offset chunk |
| will not exist and offsets are stored as in IDX v1. |
| If there is at least one offset value larger than 2^32-1, then |
| the large offset chunk must exist, and offsets larger than |
| 2^31-1 must be stored in it instead. If the large offset chunk |
| exists and the 31st bit is on, then removing that bit reveals |
| the row in the large offsets containing the 8-byte offset of |
| this object. |
| |
| [Optional] Object Large Offsets (ID: {'L', 'O', 'F', 'F'}) |
| 8-byte offsets into large packfiles. |
| |
| [Optional] Bitmap pack order (ID: {'R', 'I', 'D', 'X'}) |
| A list of MIDX positions (one per object in the MIDX, num_objects in |
| total, each a 4-byte unsigned integer in network byte order), sorted |
| according to their relative bitmap/pseudo-pack positions. |
| |
| TRAILER: |
| |
| Index checksum of the above contents. |
| |
| == multi-pack-index reverse indexes |
| |
| Similar to the pack-based reverse index, the multi-pack index can also |
| be used to generate a reverse index. |
| |
| Instead of mapping between offset, pack-, and index position, this |
| reverse index maps between an object's position within the MIDX, and |
| that object's position within a pseudo-pack that the MIDX describes |
| (i.e., the ith entry of the multi-pack reverse index holds the MIDX |
| position of ith object in pseudo-pack order). |
| |
| To clarify the difference between these orderings, consider a multi-pack |
| reachability bitmap (which does not yet exist, but is what we are |
| building towards here). Each bit needs to correspond to an object in the |
| MIDX, and so we need an efficient mapping from bit position to MIDX |
| position. |
| |
| One solution is to let bits occupy the same position in the oid-sorted |
| index stored by the MIDX. But because oids are effectively random, their |
| resulting reachability bitmaps would have no locality, and thus compress |
| poorly. (This is the reason that single-pack bitmaps use the pack |
| ordering, and not the .idx ordering, for the same purpose.) |
| |
| So we'd like to define an ordering for the whole MIDX based around |
| pack ordering, which has far better locality (and thus compresses more |
| efficiently). We can think of a pseudo-pack created by the concatenation |
| of all of the packs in the MIDX. E.g., if we had a MIDX with three packs |
| (a, b, c), with 10, 15, and 20 objects respectively, we can imagine an |
| ordering of the objects like: |
| |
| |a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19| |
| |
| where the ordering of the packs is defined by the MIDX's pack list, |
| and then the ordering of objects within each pack is the same as the |
| order in the actual packfile. |
| |
| Given the list of packs and their counts of objects, you can |
| naïvely reconstruct that pseudo-pack ordering (e.g., the object at |
| position 27 must be (c,1) because packs "a" and "b" consumed 25 of the |
| slots). But there's a catch. Objects may be duplicated between packs, in |
| which case the MIDX only stores one pointer to the object (and thus we'd |
| want only one slot in the bitmap). |
| |
| Callers could handle duplicates themselves by reading objects in order |
| of their bit-position, but that's linear in the number of objects, and |
| much too expensive for ordinary bitmap lookups. Building a reverse index |
| solves this, since it is the logical inverse of the index, and that |
| index has already removed duplicates. But, building a reverse index on |
| the fly can be expensive. Since we already have an on-disk format for |
| pack-based reverse indexes, let's reuse it for the MIDX's pseudo-pack, |
| too. |
| |
| Objects from the MIDX are ordered as follows to string together the |
| pseudo-pack. Let `pack(o)` return the pack from which `o` was selected |
| by the MIDX, and define an ordering of packs based on their numeric ID |
| (as stored by the MIDX). Let `offset(o)` return the object offset of `o` |
| within `pack(o)`. Then, compare `o1` and `o2` as follows: |
| |
| - If one of `pack(o1)` and `pack(o2)` is preferred and the other |
| is not, then the preferred one sorts first. |
| + |
| (This is a detail that allows the MIDX bitmap to determine which |
| pack should be used by the pack-reuse mechanism, since it can ask |
| the MIDX for the pack containing the object at bit position 0). |
| |
| - If `pack(o1) ≠ pack(o2)`, then sort the two objects in descending |
| order based on the pack ID. |
| |
| - Otherwise, `pack(o1) = pack(o2)`, and the objects are sorted in |
| pack-order (i.e., `o1` sorts ahead of `o2` exactly when `offset(o1) |
| < offset(o2)`). |
| |
| In short, a MIDX's pseudo-pack is the de-duplicated concatenation of |
| objects in packs stored by the MIDX, laid out in pack order, and the |
| packs arranged in MIDX order (with the preferred pack coming first). |
| |
| The MIDX's reverse index is stored in the optional 'RIDX' chunk within |
| the MIDX itself. |