docs: move pack format docs to man section 5

Continue the move of existing Documentation/technical/* protocol and
file-format documentation into our main documentation space by moving
the various documentation pertaining to the *.pack format and related
files, and updating things that refer to it to link to the new
location.

By moving these we can properly link from the newly created
gitformat-commit-graph to a gitformat-chunk-format page.

Integrating "Documentation/technical/bitmap-format.txt" and
"Documentation/technical/cruft-packs.txt" might logically be part of
this change, but as those cover parts of the wider "pack
format" (including associated files) that's documented outside of
"Documentation/technical/pack-format.txt" let's leave those for now,
subsequent commit(s) will address those.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

3 files changed, 1 insertions, 601 deletions

diff --git a/Documentation/technical/chunk-format.txt b/Documentation/technical/chunk-format.txt
deleted file mode 100644
index f36ce42f37..0000000000
--- a/Documentation/technical/chunk-format.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-Chunk-based file formats
-========================
-
-Some file formats in Git use a common concept of "chunks" to describe
-sections of the file. This allows structured access to a large file by
-scanning a small "table of contents" for the remaining data. This common
-format is used by the `commit-graph` and `multi-pack-index` files. See
-link:technical/pack-format.html[the `multi-pack-index` format] and
-the `commit-graph` format in linkgit:gitformat-commit-graph[5] for
-how they use the chunks to describe structured data.
-
-A chunk-based file format begins with some header information custom to
-that format. That header should include enough information to identify
-the file type, format version, and number of chunks in the file. From this
-information, that file can determine the start of the chunk-based region.
-
-The chunk-based region starts with a table of contents describing where
-each chunk starts and ends. This consists of (C+1) rows of 12 bytes each,
-where C is the number of chunks. Consider the following table:
-
-  | Chunk ID (4 bytes) | Chunk Offset (8 bytes) |
-  |--------------------|------------------------|
-  | ID[0]              | OFFSET[0]              |
-  | ...                | ...                    |
-  | ID[C]              | OFFSET[C]              |
-  | 0x0000             | OFFSET[C+1]            |
-
-Each row consists of a 4-byte chunk identifier (ID) and an 8-byte offset.
-Each integer is stored in network-byte order.
-
-The chunk identifier `ID[i]` is a label for the data stored within this
-fill from `OFFSET[i]` (inclusive) to `OFFSET[i+1]` (exclusive). Thus, the
-size of the `i`th chunk is equal to the difference between `OFFSET[i+1]`
-and `OFFSET[i]`. This requires that the chunk data appears contiguously
-in the same order as the table of contents.
-
-The final entry in the table of contents must be four zero bytes. This
-confirms that the table of contents is ending and provides the offset for
-the end of the chunk-based data.
-
-Note: The chunk-based format expects that the file contains _at least_ a
-trailing hash after `OFFSET[C+1]`.
-
-Functions for working with chunk-based file formats are declared in
-`chunk-format.h`. Using these methods provide extra checks that assist
-developers when creating new file formats.
-
-Writing chunk-based file formats
---------------------------------
-
-To write a chunk-based file format, create a `struct chunkfile` by
-calling `init_chunkfile()` and pass a `struct hashfile` pointer. The
-caller is responsible for opening the `hashfile` and writing header
-information so the file format is identifiable before the chunk-based
-format begins.
-
-Then, call `add_chunk()` for each chunk that is intended for write. This
-populates the `chunkfile` with information about the order and size of
-each chunk to write. Provide a `chunk_write_fn` function pointer to
-perform the write of the chunk data upon request.
-
-Call `write_chunkfile()` to write the table of contents to the `hashfile`
-followed by each of the chunks. This will verify that each chunk wrote
-the expected amount of data so the table of contents is correct.
-
-Finally, call `free_chunkfile()` to clear the `struct chunkfile` data. The
-caller is responsible for finalizing the `hashfile` by writing the trailing
-hash and closing the file.
-
-Reading chunk-based file formats
---------------------------------
-
-To read a chunk-based file format, the file must be opened as a
-memory-mapped region. The chunk-format API expects that the entire file
-is mapped as a contiguous memory region.
-
-Initialize a `struct chunkfile` pointer with `init_chunkfile(NULL)`.
-
-After reading the header information from the beginning of the file,
-including the chunk count, call `read_table_of_contents()` to populate
-the `struct chunkfile` with the list of chunks, their offsets, and their
-sizes.
-
-Extract the data information for each chunk using `pair_chunk()` or
-`read_chunk()`:
-
-* `pair_chunk()` assigns a given pointer with the location inside the
-  memory-mapped file corresponding to that chunk's offset. If the chunk
-  does not exist, then the pointer is not modified.
-
-* `read_chunk()` takes a `chunk_read_fn` function pointer and calls it
-  with the appropriate initial pointer and size information. The function
-  is not called if the chunk does not exist. Use this method to read chunks
-  if you need to perform immediate parsing or if you need to execute logic
-  based on the size of the chunk.
-
-After calling these methods, call `free_chunkfile()` to clear the
-`struct chunkfile` data. This will not close the memory-mapped region.
-Callers are expected to own that data for the timeframe the pointers into
-the region are needed.
-
-Examples
---------
-
-These file formats use the chunk-format API, and can be used as examples
-for future formats:
-
-* *commit-graph:* see `write_commit_graph_file()` and `parse_commit_graph()`
-  in `commit-graph.c` for how the chunk-format API is used to write and
-  parse the commit-graph file format documented in
-  the commit-graph file format in linkgit:gitformat-commit-graph[5].
-
-* *multi-pack-index:* see `write_midx_internal()` and `load_multi_pack_index()`
-  in `midx.c` for how the chunk-format API is used to write and
-  parse the multi-pack-index file format documented in
-  link:technical/pack-format.html[the multi-pack-index file format].
diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 260224b033..e2ac36dd21 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -205,7 +205,7 @@ SHA-1 content.
 Object storage
 ~~~~~~~~~~~~~~
 Loose objects use zlib compression and packed objects use the packed
-format described in Documentation/technical/pack-format.txt, just like
+format described in linkgit:gitformat-pack[5], just like
 today. The content that is compressed and stored uses SHA-256 content
 instead of SHA-1 content.
 
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
deleted file mode 100644
index b520aa9c45..0000000000
--- a/Documentation/technical/pack-format.txt
+++ /dev/null
@@ -1,484 +0,0 @@
-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.
-
-== pack-*.mtimes files have the format:
-
-All 4-byte numbers are in network byte order.
-
-  - A 4-byte magic number '0x4d544d45' ('MTME').
-
-  - A 4-byte version identifier (= 1).
-
-  - A 4-byte hash function identifier (= 1 for SHA-1, 2 for SHA-256).
-
-  - A table of 4-byte unsigned integers. The ith value is the
-    modification time (mtime) of the ith object in the corresponding
-    pack by lexicographic (index) order. The mtimes count standard
-    epoch seconds.
-
-  - A trailer, containing a checksum of the corresponding packfile,
-    and a checksum of all of the above (each having length according
-    to the specified hash function).
-
-== 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.