diff options
Diffstat (limited to 'gitformat-pack.html')
| -rw-r--r-- | gitformat-pack.html | 113 |
1 files changed, 112 insertions, 1 deletions
diff --git a/gitformat-pack.html b/gitformat-pack.html index 0ec60b5ab..b5bed832f 100644 --- a/gitformat-pack.html +++ b/gitformat-pack.html @@ -1313,6 +1313,17 @@ otherwise specified.</code></pre> </div></div>
<div class="literalblock">
<div class="content">
+<pre><code>Bitmapped Packfiles (ID: {'B', 'T', 'M', 'P'})
+ Stores a table of two 4-byte unsigned integers in network order.
+ Each table entry corresponds to a single pack (in the order that
+ they appear above in the `PNAM` chunk). The values for each table
+ entry are as follows:
+ - The first bit position (in pseudo-pack order, see below) to
+ contain an object from that pack.
+ - The number of bits whose objects are selected from that pack.</code></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
<pre><code>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
@@ -1439,6 +1450,106 @@ 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).</p></div>
<div class="paragraph"><p>The MIDX’s reverse index is stored in the optional <em>RIDX</em> chunk within
the MIDX itself.</p></div>
+<div class="sect2">
+<h3 id="_code_btmp_code_chunk"><code>BTMP</code> chunk</h3>
+<div class="paragraph"><p>The Bitmapped Packfiles (<code>BTMP</code>) chunk encodes additional information
+about the objects in the multi-pack index’s reachability bitmap. Recall
+that objects from the MIDX are arranged in "pseudo-pack" order (see
+above) for reachability bitmaps.</p></div>
+<div class="paragraph"><p>From the example above, suppose we have packs "a", "b", and "c", with
+10, 15, and 20 objects, respectively. In pseudo-pack order, those would
+be arranged as follows:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><code>|a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19|</code></pre>
+</div></div>
+<div class="paragraph"><p>When working with single-pack bitmaps (or, equivalently, multi-pack
+reachability bitmaps with a preferred pack), <a href="git-pack-objects.html">git-pack-objects(1)</a>
+performs “verbatim” reuse, attempting to reuse chunks of the bitmapped
+or preferred packfile instead of adding objects to the packing list.</p></div>
+<div class="paragraph"><p>When a chunk of bytes is reused from an existing pack, any objects
+contained therein do not need to be added to the packing list, saving
+memory and CPU time. But a chunk from an existing packfile can only be
+reused when the following conditions are met:</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+The chunk contains only objects which were requested by the caller
+ (i.e. does not contain any objects which the caller didn’t ask for
+ explicitly or implicitly).
+</p>
+</li>
+<li>
+<p>
+All objects stored in non-thin packs as offset- or reference-deltas
+ also include their base object in the resulting pack.
+</p>
+</li>
+</ul></div>
+<div class="paragraph"><p>The <code>BTMP</code> chunk encodes the necessary information in order to implement
+multi-pack reuse over a set of packfiles as described above.
+Specifically, the <code>BTMP</code> chunk encodes three pieces of information (all
+32-bit unsigned integers in network byte-order) for each packfile <code>p</code>
+that is stored in the MIDX, as follows:</p></div>
+<div class="dlist"><dl>
+<dt class="hdlist1">
+<code>bitmap_pos</code>
+</dt>
+<dd>
+<p>
+The first bit position (in pseudo-pack order) in the
+ multi-pack index’s reachability bitmap occupied by an object from <code>p</code>.
+</p>
+</dd>
+<dt class="hdlist1">
+<code>bitmap_nr</code>
+</dt>
+<dd>
+<p>
+The number of bit positions (including the one at
+ <code>bitmap_pos</code>) that encode objects from that pack <code>p</code>.
+</p>
+</dd>
+</dl></div>
+<div class="paragraph"><p>For example, the <code>BTMP</code> chunk corresponding to the above example (with
+packs “a”, “b”, and “c”) would look like:</p></div>
+<div class="tableblock">
+<table rules="all"
+width="100%"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col width="20%" />
+<col width="40%" />
+<col width="40%" />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table"></p></td>
+<td align="left" valign="top"><p class="table"><code>bitmap_pos</code></p></td>
+<td align="left" valign="top"><p class="table"><code>bitmap_nr</code></p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">packfile “a”</p></td>
+<td align="left" valign="top"><p class="table"><code>0</code></p></td>
+<td align="left" valign="top"><p class="table"><code>10</code></p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">packfile “b”</p></td>
+<td align="left" valign="top"><p class="table"><code>10</code></p></td>
+<td align="left" valign="top"><p class="table"><code>15</code></p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">packfile “c”</p></td>
+<td align="left" valign="top"><p class="table"><code>25</code></p></td>
+<td align="left" valign="top"><p class="table"><code>20</code></p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>With this information in place, we can treat each packfile as
+individually reusable in the same fashion as verbatim pack reuse is
+performed on individual packs prior to the implementation of the <code>BTMP</code>
+chunk.</p></div>
+</div>
</div>
</div>
<div class="sect1">
@@ -1553,7 +1664,7 @@ support for optional chunks of data, it may make sense to consolidate the <div id="footer">
<div id="footer-text">
Last updated
- 2023-11-08 09:04:31 PST
+ 2024-01-12 16:26:54 PST
</div>
</div>
</body>
|