Skip to content

Commit c9425ef

Browse files
gitstergitster
committed
Autogenerated HTML docs for v2.49.0-221-g485f5
1 parent 9afc49c commit c9425ef

File tree

5 files changed

+213
-25
lines changed

5 files changed

+213
-25
lines changed

Diff for: ‎RelNotes/2.50.0.adoc

+25-2
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,11 @@ UI, Workflows & Features
1010
* "git repack" learned "--combine-cruft-below-size" option that
1111
controls how cruft-packs are combined.
1212

13+
* TCP keepalive behaviour on http transports can now be configured by
14+
calling cURL library.
15+
16+
* Incrementally updating multi-pack index files.
17+
1318

1419
Performance, Internal Implementation, Development Support etc.
1520
--------------------------------------------------------------
@@ -37,8 +42,18 @@ Performance, Internal Implementation, Development Support etc.
3742
3843
* Enable -Wunreachable-code for developer builds.
3944
40-
* Build update.
41-
(merge 7c8cd9c158 es/meson-building-docs-requires-perl later to maint).
45+
* Ensure what we write in assert() does not have side effects,
46+
and introduce ASSERT() macro to mark those that cannot be
47+
mechanically checked for lack of side effects.
48+
49+
* Give more meaningful error return values from block writer layer of
50+
the reftable ref-API backend.
51+
52+
* Make the code in reftable library less reliant on the service
53+
routines it used to borrow from Git proper, to make it easier to
54+
use by external users of the library.
55+
56+
* CI update.
4257
4358
4459
Fixes since v2.49
@@ -88,6 +103,10 @@ Fixes since v2.49
88103
* "Dubious ownership" checks on Windows has been tightened up.
89104
(merge 5bb88e89ef js/mingw-admins-are-special later to maint).
90105

106+
* Layout configuration in vimdiff backend didn't work as advertised,
107+
which has been corrected.
108+
(merge 93bab2d04b fr/vimdiff-layout-fixes later to maint).
109+
91110
* Other code cleanup, docfix, build fix, etc.
92111
(merge 227c4f33a0 ja/doc-block-delimiter-markup-fix later to maint).
93112
(merge 2bfd3b3685 ab/decorate-code-cleanup later to maint).
@@ -101,3 +120,7 @@ Fixes since v2.49
101120
(merge ee434e1807 pw/doc-pack-refs-markup-fix later to maint).
102121
(merge c000918eb7 tb/bitamp-typofix later to maint).
103122
(merge fa8cd29676 js/imap-send-peer-cert-verify later to maint).
123+
(merge 98b423bc1c rs/clear-commit-marks-simplify later to maint).
124+
(merge 133d065dd6 ta/bulk-checkin-signed-compare-false-warning-fix later to maint).
125+
(merge d2827dc31e es/meson-build-skip-coccinelle later to maint).
126+
(merge ee8edb7156 dk/vimdiff-doc-fix later to maint).

Diff for: ‎git-config.html

+21
Original file line numberDiff line numberDiff line change
@@ -6146,6 +6146,27 @@ <h3 id="_variables">Variables</h3>
61466146
Can be overridden by the <code>GIT_HTTP_LOW_SPEED_LIMIT</code> and
61476147
<code>GIT_HTTP_LOW_SPEED_TIME</code> environment variables.</p>
61486148
</dd>
6149+
<dt class="hdlist1">http.keepAliveIdle</dt>
6150+
<dd>
6151+
<p>Specifies how long in seconds to wait on an idle connection
6152+
before sending TCP keepalive probes (if supported by the OS). If
6153+
unset, curl&#8217;s default value is used. Can be overridden by the
6154+
<code>GIT_HTTP_KEEPALIVE_IDLE</code> environment variable.</p>
6155+
</dd>
6156+
<dt class="hdlist1">http.keepAliveInterval</dt>
6157+
<dd>
6158+
<p>Specifies how long in seconds to wait between TCP keepalive
6159+
probes (if supported by the OS). If unset, curl&#8217;s default value
6160+
is used. Can be overridden by the <code>GIT_HTTP_KEEPALIVE_INTERVAL</code>
6161+
environment variable.</p>
6162+
</dd>
6163+
<dt class="hdlist1">http.keepAliveCount</dt>
6164+
<dd>
6165+
<p>Specifies how many TCP keepalive probes to send before giving up
6166+
and terminating the connection (if supported by the OS). If
6167+
unset, curl&#8217;s default value is used. Can be overridden by the
6168+
<code>GIT_HTTP_KEEPALIVE_COUNT</code> environment variable.</p>
6169+
</dd>
61496170
<dt class="hdlist1">http.noEPSV</dt>
61506171
<dd>
61516172
<p>A boolean which disables using of EPSV ftp command by curl.

Diff for: ‎git-mergetool.html

+1-1
Original file line numberDiff line numberDiff line change
@@ -850,7 +850,7 @@ <h4 id="_layout_configuration">Layout configuration</h4>
850850
<div class="content">
851851
<div class="paragraph">
852852
<p>When <code>MERGED</code> is not present in the layout, you must "mark" one of the
853-
buffers with an asterisk. That will become the buffer you need to edit and
853+
buffers with an arobase (<code>@</code>). That will become the buffer you need to edit and
854854
save after resolving the conflicts.</p>
855855
</div>
856856
<div class="literalblock">

Diff for: ‎technical/multi-pack-index.adoc

+72-10
Original file line numberDiff line numberDiff line change
@@ -164,19 +164,81 @@ objects_nr($H2) + objects_nr($H1) + i
164164
(in the C implementation, this is often computed as `i +
165165
m->num_objects_in_base`).
166166

167+
=== Pseudo-pack order for incremental MIDXs
168+
169+
The original implementation of multi-pack reachability bitmaps defined
170+
the pseudo-pack order in linkgit:gitformat-pack[5] (see the section
171+
titled "multi-pack-index reverse indexes") roughly as follows:
172+
173+
____
174+
In short, a MIDX's pseudo-pack is the de-duplicated concatenation of
175+
objects in packs stored by the MIDX, laid out in pack order, and the
176+
packs arranged in MIDX order (with the preferred pack coming first).
177+
____
178+
179+
In the incremental MIDX design, we extend this definition to include
180+
objects from multiple layers of the MIDX chain. The pseudo-pack order
181+
for incremental MIDXs is determined by concatenating the pseudo-pack
182+
ordering for each layer of the MIDX chain in order. Formally two objects
183+
`o1` and `o2` are compared as follows:
184+
185+
1. If `o1` appears in an earlier layer of the MIDX chain than `o2`, then
186+
`o1` sorts ahead of `o2`.
187+
188+
2. Otherwise, if `o1` and `o2` appear in the same MIDX layer, and that
189+
MIDX layer has no base, then if one of `pack(o1)` and `pack(o2)` is
190+
preferred and the other is not, then the preferred one sorts ahead of
191+
the non-preferred one. If there is a base layer (i.e. the MIDX layer
192+
is not the first layer in the chain), then if `pack(o1)` appears
193+
earlier in that MIDX layer's pack order, then `o1` sorts ahead of
194+
`o2`. Likewise if `pack(o2)` appears earlier, then the opposite is
195+
true.
196+
197+
3. Otherwise, `o1` and `o2` appear in the same pack, and thus in the
198+
same MIDX layer. Sort `o1` and `o2` by their offset within their
199+
containing packfile.
200+
201+
Note that the preferred pack is a property of the MIDX chain, not the
202+
individual layers themselves. Fundamentally we could introduce a
203+
per-layer preferred pack, but this is less relevant now that we can
204+
perform multi-pack reuse across the set of packs in a MIDX.
205+
206+
=== Reachability bitmaps and incremental MIDXs
207+
208+
Each layer of an incremental MIDX chain may have its objects (and the
209+
objects from any previous layer in the same MIDX chain) represented in
210+
its own `*.bitmap` file.
211+
212+
The structure of a `*.bitmap` file belonging to an incremental MIDX
213+
chain is identical to that of a non-incremental MIDX bitmap, or a
214+
classic single-pack bitmap. Since objects are added to the end of the
215+
incremental MIDX's pseudo-pack order (see above), it is possible to
216+
extend a bitmap when appending to the end of a MIDX chain.
217+
218+
(Note: it is possible likewise to compress a contiguous sequence of MIDX
219+
incremental layers, and their `*.bitmap` files into a single layer and
220+
`*.bitmap`, but this is not yet implemented.)
221+
222+
The object positions used are global within the pseudo-pack order, so
223+
subsequent layers will have, for example, `m->num_objects_in_base`
224+
number of `0` bits in each of their four type bitmaps. This follows from
225+
the fact that we only write type bitmap entries for objects present in
226+
the layer immediately corresponding to the bitmap).
227+
228+
Note also that only the bitmap pertaining to the most recent layer in an
229+
incremental MIDX chain is used to store reachability information about
230+
the interesting and uninteresting objects in a reachability query.
231+
Earlier bitmap layers are only used to look up commit and pseudo-merge
232+
bitmaps from that layer, as well as the type-level bitmaps for objects
233+
in that layer.
234+
235+
To simplify the implementation, type-level bitmaps are iterated
236+
simultaneously, and their results are OR'd together to avoid recursively
237+
calling internal bitmap functions.
238+
167239
Future Work
168240
-----------
169241
170-
- The multi-pack-index allows many packfiles, especially in a context
171-
where repacking is expensive (such as a very large repo), or
172-
unexpected maintenance time is unacceptable (such as a high-demand
173-
build machine). However, the multi-pack-index needs to be rewritten
174-
in full every time. We can extend the format to be incremental, so
175-
writes are fast. By storing a small "tip" multi-pack-index that
176-
points to large "base" MIDX files, we can keep writes fast while
177-
still reducing the number of binary searches required for object
178-
lookups.
179-
180242
- If the multi-pack-index is extended to store a "stable object order"
181243
(a function Order(hash) = integer that is constant for a given hash,
182244
even as the multi-pack-index is updated) then MIDX bitmaps could be

Diff for: ‎technical/multi-pack-index.html

+94-12
Original file line numberDiff line numberDiff line change
@@ -673,6 +673,99 @@ <h3 id="_object_positions_for_incremental_midxs">Object positions for incrementa
673673
<code>m-</code>&gt;<code>num_objects_in_base</code>).</p>
674674
</div>
675675
</div>
676+
<div class="sect2">
677+
<h3 id="_pseudo_pack_order_for_incremental_midxs">Pseudo-pack order for incremental MIDXs</h3>
678+
<div class="paragraph">
679+
<p>The original implementation of multi-pack reachability bitmaps defined
680+
the pseudo-pack order in <a href="../gitformat-pack.html">gitformat-pack(5)</a> (see the section
681+
titled "multi-pack-index reverse indexes") roughly as follows:</p>
682+
</div>
683+
<div class="quoteblock">
684+
<blockquote>
685+
<div class="paragraph">
686+
<p>In short, a MIDX&#8217;s pseudo-pack is the de-duplicated concatenation of
687+
objects in packs stored by the MIDX, laid out in pack order, and the
688+
packs arranged in MIDX order (with the preferred pack coming first).</p>
689+
</div>
690+
</blockquote>
691+
</div>
692+
<div class="paragraph">
693+
<p>In the incremental MIDX design, we extend this definition to include
694+
objects from multiple layers of the MIDX chain. The pseudo-pack order
695+
for incremental MIDXs is determined by concatenating the pseudo-pack
696+
ordering for each layer of the MIDX chain in order. Formally two objects
697+
<code>o1</code> and <code>o2</code> are compared as follows:</p>
698+
</div>
699+
<div class="olist arabic">
700+
<ol class="arabic">
701+
<li>
702+
<p>If <code>o1</code> appears in an earlier layer of the MIDX chain than <code>o2</code>, then
703+
<code>o1</code> sorts ahead of <code>o2</code>.</p>
704+
</li>
705+
<li>
706+
<p>Otherwise, if <code>o1</code> and <code>o2</code> appear in the same MIDX layer, and that
707+
MIDX layer has no base, then if one of <code>pack</code>(<code>o1</code>) and <code>pack</code>(<code>o2</code>) is
708+
preferred and the other is not, then the preferred one sorts ahead of
709+
the non-preferred one. If there is a base layer (i.e. the MIDX layer
710+
is not the first layer in the chain), then if <code>pack</code>(<code>o1</code>) appears
711+
earlier in that MIDX layer&#8217;s pack order, then <code>o1</code> sorts ahead of
712+
<code>o2</code>. Likewise if <code>pack</code>(<code>o2</code>) appears earlier, then the opposite is
713+
true.</p>
714+
</li>
715+
<li>
716+
<p>Otherwise, <code>o1</code> and <code>o2</code> appear in the same pack, and thus in the
717+
same MIDX layer. Sort <code>o1</code> and <code>o2</code> by their offset within their
718+
containing packfile.</p>
719+
</li>
720+
</ol>
721+
</div>
722+
<div class="paragraph">
723+
<p>Note that the preferred pack is a property of the MIDX chain, not the
724+
individual layers themselves. Fundamentally we could introduce a
725+
per-layer preferred pack, but this is less relevant now that we can
726+
perform multi-pack reuse across the set of packs in a MIDX.</p>
727+
</div>
728+
</div>
729+
<div class="sect2">
730+
<h3 id="_reachability_bitmaps_and_incremental_midxs">Reachability bitmaps and incremental MIDXs</h3>
731+
<div class="paragraph">
732+
<p>Each layer of an incremental MIDX chain may have its objects (and the
733+
objects from any previous layer in the same MIDX chain) represented in
734+
its own *.<code>bitmap</code> file.</p>
735+
</div>
736+
<div class="paragraph">
737+
<p>The structure of a *.<code>bitmap</code> file belonging to an incremental MIDX
738+
chain is identical to that of a non-incremental MIDX bitmap, or a
739+
classic single-pack bitmap. Since objects are added to the end of the
740+
incremental MIDX&#8217;s pseudo-pack order (see above), it is possible to
741+
extend a bitmap when appending to the end of a MIDX chain.</p>
742+
</div>
743+
<div class="paragraph">
744+
<p>(Note: it is possible likewise to compress a contiguous sequence of MIDX
745+
incremental layers, and their *.<code>bitmap</code> files into a single layer and
746+
*.<code>bitmap</code>, but this is not yet implemented.)</p>
747+
</div>
748+
<div class="paragraph">
749+
<p>The object positions used are global within the pseudo-pack order, so
750+
subsequent layers will have, for example, <code>m-</code>&gt;<code>num_objects_in_base</code>
751+
number of <code>0</code> bits in each of their four type bitmaps. This follows from
752+
the fact that we only write type bitmap entries for objects present in
753+
the layer immediately corresponding to the bitmap).</p>
754+
</div>
755+
<div class="paragraph">
756+
<p>Note also that only the bitmap pertaining to the most recent layer in an
757+
incremental MIDX chain is used to store reachability information about
758+
the interesting and uninteresting objects in a reachability query.
759+
Earlier bitmap layers are only used to look up commit and pseudo-merge
760+
bitmaps from that layer, as well as the type-level bitmaps for objects
761+
in that layer.</p>
762+
</div>
763+
<div class="paragraph">
764+
<p>To simplify the implementation, type-level bitmaps are iterated
765+
simultaneously, and their results are OR&#8217;d together to avoid recursively
766+
calling internal bitmap functions.</p>
767+
</div>
768+
</div>
676769
</div>
677770
</div>
678771
<div class="sect1">
@@ -681,17 +774,6 @@ <h2 id="_future_work">Future Work</h2>
681774
<div class="ulist">
682775
<ul>
683776
<li>
684-
<p>The multi-pack-index allows many packfiles, especially in a context
685-
where repacking is expensive (such as a very large repo), or
686-
unexpected maintenance time is unacceptable (such as a high-demand
687-
build machine). However, the multi-pack-index needs to be rewritten
688-
in full every time. We can extend the format to be incremental, so
689-
writes are fast. By storing a small "tip" multi-pack-index that
690-
points to large "base" MIDX files, we can keep writes fast while
691-
still reducing the number of binary searches required for object
692-
lookups.</p>
693-
</li>
694-
<li>
695777
<p>If the multi-pack-index is extended to store a "stable object order"
696778
(a function Order(hash) = integer that is constant for a given hash,
697779
even as the multi-pack-index is updated) then MIDX bitmaps could be
@@ -731,7 +813,7 @@ <h2 id="_related_links">Related Links</h2>
731813
</div>
732814
<div id="footer">
733815
<div id="footer-text">
734-
Last updated 2025-02-14 21:38:14 -0800
816+
Last updated 2025-04-08 12:12:27 -0700
735817
</div>
736818
</div>
737819
</body>

0 commit comments

Comments
 (0)