Autogenerated HTML docs for v2.42.0-482-g2e8e7

1 files changed, 11 insertions, 11 deletions

diff --git a/gitprotocol-capabilities.html b/gitprotocol-capabilities.html
index e653f9321..3b4d5dec2 100644
--- a/gitprotocol-capabilities.html
+++ b/gitprotocol-capabilities.html
@@ -777,7 +777,7 @@ to the client.</p></div>
 to be in effect. The client MUST NOT ask for capabilities the server

 did not say it supports.</p></div>

 <div class="paragraph"><p>Server MUST diagnose and abort if capabilities it does not understand

-was sent.  Server MUST NOT ignore capabilities that client requested

+were sent.  Server MUST NOT ignore capabilities that client requested

 and server advertised.  As a consequence of these rules, server MUST

 NOT advertise capabilities it does not understand.</p></div>

 <div class="paragraph"><p>The <em>atomic</em>, <em>report-status</em>, <em>report-status-v2</em>, <em>delete-refs</em>, <em>quiet</em>,

@@ -804,8 +804,8 @@ complete cut across the DAG, or the client has said "done".</p></div>
 <div class="paragraph"><p>Without multi_ack, a client sends have lines in --date-order until

 the server has found a common base.  That means the client will send

 have lines that are already known by the server to be common, because

-they overlap in time with another branch that the server hasn&#8217;t found

-a common base on yet.</p></div>

+they overlap in time with another branch on which the server hasn&#8217;t found

+a common base yet.</p></div>

 <div class="paragraph"><p>For example suppose the client has commits in caps that the server

 doesn&#8217;t and the server has commits in lower case that the client

 doesn&#8217;t, as in the following diagram:</p></div>

@@ -832,7 +832,7 @@ interleaved with S-R-Q.</p></div>
 <div class="sect1">

 <h2 id="_multi_ack_detailed">multi_ack_detailed</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>This is an extension of multi_ack that permits client to better

+<div class="paragraph"><p>This is an extension of multi_ack that permits the client to better

 understand the server&#8217;s in-memory state. See <a href="gitprotocol-pack.html">gitprotocol-pack(5)</a>,

 section "Packfile Negotiation" for more information.</p></div>

 </div>

@@ -878,7 +878,7 @@ to disable the feature in a backwards-compatible manner.</p></div>
 <div class="sect1">

 <h2 id="_side_band_side_band_64k">side-band, side-band-64k</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>This capability means that server can send, and client understand multiplexed

+<div class="paragraph"><p>This capability means that the server can send, and the client can understand, multiplexed

 progress reports and error info interleaved with the packfile itself.</p></div>

 <div class="paragraph"><p>These two options are mutually exclusive. A modern client always

 favors <em>side-band-64k</em>.</p></div>

@@ -902,15 +902,15 @@ for the older clients.</p></div>
 999 bytes of payload and 1 byte for the stream code. With side-band-64k,

 same deal, you have up to 65519 bytes of data and 1 byte for the stream

 code.</p></div>

-<div class="paragraph"><p>The client MUST send only maximum of one of "side-band" and "side-

-band-64k".  Server MUST diagnose it as an error if client requests

+<div class="paragraph"><p>The client MUST send only one of "side-band" and "side-

+band-64k".  The server MUST diagnose it as an error if client requests

 both.</p></div>

 </div>

 </div>

 <div class="sect1">

 <h2 id="_ofs_delta">ofs-delta</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Server can send, and client understand PACKv2 with delta referring to

+<div class="paragraph"><p>The server can send, and the client can understand, PACKv2 with delta referring to

 its base by position in pack rather than by an obj-id.  That is, they can

 send/read OBJ_OFS_DELTA (aka type 6) in a packfile.</p></div>

 </div>

@@ -996,7 +996,7 @@ the current shallow boundary, instead of the depth from remote refs.</p></div>
 <div class="sect1">

 <h2 id="_no_progress">no-progress</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>The client was started with "git clone -q" or something, and doesn&#8217;t

+<div class="paragraph"><p>The client was started with "git clone -q" or something similar, and doesn&#8217;t

 want that side band 2.  Basically the client just says "I do not

 wish to receive stream 2 on sideband, so do not send it to me, and if

 you did, I will drop it on the floor anyway".  However, the sideband

@@ -1016,7 +1016,7 @@ the server advertises this capability. The decision for a client to
 request include-tag only has to do with the client&#8217;s desires for tag

 data, whether or not a server had advertised objects in the

 refs/tags/* namespace.</p></div>

-<div class="paragraph"><p>Servers MUST pack the tags if their referrant is packed and the client

+<div class="paragraph"><p>Servers MUST pack the tags if their referent is packed and the client

 has requested include-tags.</p></div>

 <div class="paragraph"><p>Clients MUST be prepared for the case where a server has ignored

 include-tag and has not actually sent tags in the pack.  In such

@@ -1154,7 +1154,7 @@ and users of the session ID should not rely on this fact.</p></div>
 <div id="footer">

 <div id="footer-text">

 Last updated

- 2022-09-21 15:44:34 PDT

+ 2023-10-23 14:43:46 PDT

 </div>

 </div>

 </body>