Skip to content

Commit 6076a3f

Browse files
gitstergitster
committed
Autogenerated HTML docs for v2.49.0-rc1-37-ge969b
1 parent 18f46c2 commit 6076a3f

6 files changed

+830
-7
lines changed

‎BreakingChanges.adoc

+5-6
Original file line numberDiff line numberDiff line change
@@ -66,22 +66,21 @@ changes are made at a certain version boundary, and recording these
6666
decisions in this document, are necessary but not sufficient.
6767
Because such changes are expected to be numerous, and the design and
6868
implementation of them are expected to span over time, they have to
69-
be deployable trivially at such a version boundary.
69+
be deployable trivially at such a version boundary, prepared over long
70+
time.
7071

7172
The breaking changes MUST be guarded with the a compile-time switch,
7273
WITH_BREAKING_CHANGES, to help this process. When built with it,
7374
the resulting Git binary together with its documentation would
7475
behave as if these breaking changes slated for the next big version
75-
boundary are already in effect. We may also want to have a CI job
76-
or two to exercise the work-in-progress version of Git with these
77-
breaking changes.
76+
boundary are already in effect. We also have a CI job to exercise
77+
the work-in-progress version of Git with these breaking changes.
7878

7979

8080
== Git 3.0
8181

8282
The following subsections document upcoming breaking changes for Git 3.0. There
83-
is no planned release date for this breaking version yet. The early
84-
adopter configuration used for changes for this release is `feature.git3`.
83+
is no planned release date for this breaking version yet.
8584

8685
Proposed changes and removals only include items which are "ready" to be done.
8786
In other words, this is not supposed to be a wishlist of features that should

‎RelNotes/2.49.0.adoc

+13
Original file line numberDiff line numberDiff line change
@@ -93,6 +93,18 @@ Performance, Internal Implementation, Development Support etc.
9393
* Rename processing in the recursive merge backend has seen a micro
9494
optimization.
9595
96+
* The path.[ch] API takes an explicit repository parameter passed
97+
throughout the callchain, instead of relying on the_repository
98+
singleton instance.
99+
100+
* Large-object promisor protocol extension has been introduced.
101+
102+
* The editorconfig file is updated to tell us that bash scripts are
103+
similar to general Bourne shell scripts.
104+
105+
* Meson-based build procedure forgot to build some docs, which has
106+
been corrected.
107+
96108
97109
Fixes since v2.48
98110
-----------------
@@ -272,3 +284,4 @@ Fixes since v2.48
272284
(merge 45761988ac en/doc-renormalize later to maint).
273285
(merge 832f56f06a jc/doc-boolean-synonyms later to maint).
274286
(merge 3eeed876a9 ac/doc-http-ssl-type-config later to maint).
287+
(merge c268e3285d jc/breaking-changes-early-adopter-option later to maint).

‎git-config.html

+29
Original file line numberDiff line numberDiff line change
@@ -7380,6 +7380,35 @@ <h3 id="_variables">Variables</h3>
73807380
<p>If set to "true" assume <code>--quiet</code> when fetching additional
73817381
objects for a partial clone.</p>
73827382
</dd>
7383+
<dt class="hdlist1">promisor.advertise</dt>
7384+
<dd>
7385+
<p>If set to "true", a server will use the "promisor-remote"
7386+
capability, see <a href="gitprotocol-v2.html">gitprotocol-v2(5)</a>, to advertise the
7387+
promisor remotes it is using, if it uses some. Default is
7388+
"false", which means the "promisor-remote" capability is not
7389+
advertised.</p>
7390+
</dd>
7391+
<dt class="hdlist1">promisor.acceptFromServer</dt>
7392+
<dd>
7393+
<p>If set to "all", a client will accept all the promisor remotes
7394+
a server might advertise using the "promisor-remote"
7395+
capability. If set to "knownName" the client will accept
7396+
promisor remotes which are already configured on the client
7397+
and have the same name as those advertised by the client. This
7398+
is not very secure, but could be used in a corporate setup
7399+
where servers and clients are trusted to not switch name and
7400+
URLs. If set to "knownUrl", the client will accept promisor
7401+
remotes which have both the same name and the same URL
7402+
configured on the client as the name and URL advertised by the
7403+
server. This is more secure than "all" or "knownName", so it
7404+
should be used if possible instead of those options. Default
7405+
is "none", which means no promisor remote advertised by a
7406+
server will be accepted. By accepting a promisor remote, the
7407+
client agrees that the server might omit objects that are
7408+
lazily fetchable from this promisor remote from its responses
7409+
to "fetch" and "clone" requests from the client. See
7410+
<a href="gitprotocol-v2.html">gitprotocol-v2(5)</a>.</p>
7411+
</dd>
73837412
<dt class="hdlist1">protocol.allow</dt>
73847413
<dd>
73857414
<p>If set, provide a user defined default policy for all protocols which

‎gitprotocol-v2.adoc

+54
Original file line numberDiff line numberDiff line change
@@ -785,6 +785,60 @@ retrieving the header from a bundle at the indicated URI, and thus
785785
save themselves and the server(s) the request(s) needed to inspect the
786786
headers of that bundle or bundles.
787787
788+
promisor-remote=<pr-infos>
789+
~~~~~~~~~~~~~~~~~~~~~~~~~~
790+
791+
The server may advertise some promisor remotes it is using or knows
792+
about to a client which may want to use them as its promisor remotes,
793+
instead of this repository. In this case <pr-infos> should be of the
794+
form:
795+
796+
pr-infos = pr-info | pr-infos ";" pr-info
797+
798+
pr-info = "name=" pr-name | "name=" pr-name "," "url=" pr-url
799+
800+
where `pr-name` is the urlencoded name of a promisor remote, and
801+
`pr-url` the urlencoded URL of that promisor remote.
802+
803+
In this case, if the client decides to use one or more promisor
804+
remotes the server advertised, it can reply with
805+
"promisor-remote=<pr-names>" where <pr-names> should be of the form:
806+
807+
pr-names = pr-name | pr-names ";" pr-name
808+
809+
where `pr-name` is the urlencoded name of a promisor remote the server
810+
advertised and the client accepts.
811+
812+
Note that, everywhere in this document, `pr-name` MUST be a valid
813+
remote name, and the ';' and ',' characters MUST be encoded if they
814+
appear in `pr-name` or `pr-url`.
815+
816+
If the server doesn't know any promisor remote that could be good for
817+
a client to use, or prefers a client not to use any promisor remote it
818+
uses or knows about, it shouldn't advertise the "promisor-remote"
819+
capability at all.
820+
821+
In this case, or if the client doesn't want to use any promisor remote
822+
the server advertised, the client shouldn't advertise the
823+
"promisor-remote" capability at all in its reply.
824+
825+
The "promisor.advertise" and "promisor.acceptFromServer" configuration
826+
options can be used on the server and client side to control what they
827+
advertise or accept respectively. See the documentation of these
828+
configuration options for more information.
829+
830+
Note that in the future it would be nice if the "promisor-remote"
831+
protocol capability could be used by the server, when responding to
832+
`git fetch` or `git clone`, to advertise better-connected remotes that
833+
the client can use as promisor remotes, instead of this repository, so
834+
that the client can lazily fetch objects from these other
835+
better-connected remotes. This would require the server to omit in its
836+
response the objects available on the better-connected remotes that
837+
the client has accepted. This hasn't been implemented yet though. So
838+
for now this "promisor-remote" capability is useful only when the
839+
server advertises some promisor remotes it already uses to borrow
840+
objects from.
841+
788842
GIT
789843
---
790844
Part of the linkgit:git[1] suite

‎gitprotocol-v2.html

+73-1
Original file line numberDiff line numberDiff line change
@@ -1517,6 +1517,78 @@ <h4 id="_bundle_uri_protocol_features">bundle-uri PROTOCOL FEATURES</h4>
15171517
</div>
15181518
</div>
15191519
</div>
1520+
<div class="sect2">
1521+
<h3 id="_promisor_remotepr_infos">promisor-remote=&lt;pr-infos&gt;</h3>
1522+
<div class="paragraph">
1523+
<p>The server may advertise some promisor remotes it is using or knows
1524+
about to a client which may want to use them as its promisor remotes,
1525+
instead of this repository. In this case &lt;pr-infos&gt; should be of the
1526+
form:</p>
1527+
</div>
1528+
<div class="literalblock">
1529+
<div class="content">
1530+
<pre>pr-infos = pr-info | pr-infos ";" pr-info</pre>
1531+
</div>
1532+
</div>
1533+
<div class="literalblock">
1534+
<div class="content">
1535+
<pre>pr-info = "name=" pr-name | "name=" pr-name "," "url=" pr-url</pre>
1536+
</div>
1537+
</div>
1538+
<div class="paragraph">
1539+
<p>where <code>pr-name</code> is the urlencoded name of a promisor remote, and
1540+
<code>pr-url</code> the urlencoded URL of that promisor remote.</p>
1541+
</div>
1542+
<div class="paragraph">
1543+
<p>In this case, if the client decides to use one or more promisor
1544+
remotes the server advertised, it can reply with
1545+
"promisor-remote=&lt;pr-names&gt;" where &lt;pr-names&gt; should be of the form:</p>
1546+
</div>
1547+
<div class="literalblock">
1548+
<div class="content">
1549+
<pre>pr-names = pr-name | pr-names ";" pr-name</pre>
1550+
</div>
1551+
</div>
1552+
<div class="paragraph">
1553+
<p>where <code>pr-name</code> is the urlencoded name of a promisor remote the server
1554+
advertised and the client accepts.</p>
1555+
</div>
1556+
<div class="paragraph">
1557+
<p>Note that, everywhere in this document, <code>pr-name</code> MUST be a valid
1558+
remote name, and the <em>;</em> and <em>,</em> characters MUST be encoded if they
1559+
appear in <code>pr-name</code> or <code>pr-url</code>.</p>
1560+
</div>
1561+
<div class="paragraph">
1562+
<p>If the server doesn&#8217;t know any promisor remote that could be good for
1563+
a client to use, or prefers a client not to use any promisor remote it
1564+
uses or knows about, it shouldn&#8217;t advertise the "promisor-remote"
1565+
capability at all.</p>
1566+
</div>
1567+
<div class="paragraph">
1568+
<p>In this case, or if the client doesn&#8217;t want to use any promisor remote
1569+
the server advertised, the client shouldn&#8217;t advertise the
1570+
"promisor-remote" capability at all in its reply.</p>
1571+
</div>
1572+
<div class="paragraph">
1573+
<p>The "promisor.advertise" and "promisor.acceptFromServer" configuration
1574+
options can be used on the server and client side to control what they
1575+
advertise or accept respectively. See the documentation of these
1576+
configuration options for more information.</p>
1577+
</div>
1578+
<div class="paragraph">
1579+
<p>Note that in the future it would be nice if the "promisor-remote"
1580+
protocol capability could be used by the server, when responding to
1581+
<code>git</code> <code>fetch</code> or <code>git</code> <code>clone</code>, to advertise better-connected remotes that
1582+
the client can use as promisor remotes, instead of this repository, so
1583+
that the client can lazily fetch objects from these other
1584+
better-connected remotes. This would require the server to omit in its
1585+
response the objects available on the better-connected remotes that
1586+
the client has accepted. This hasn&#8217;t been implemented yet though. So
1587+
for now this "promisor-remote" capability is useful only when the
1588+
server advertises some promisor remotes it already uses to borrow
1589+
objects from.</p>
1590+
</div>
1591+
</div>
15201592
</div>
15211593
</div>
15221594
<div class="sect1">
@@ -1530,7 +1602,7 @@ <h2 id="_git">GIT</h2>
15301602
</div>
15311603
<div id="footer">
15321604
<div id="footer-text">
1533-
Last updated 2025-02-27 16:06:53 -0800
1605+
Last updated 2025-03-05 13:58:00 -0800
15341606
</div>
15351607
</div>
15361608
</body>

0 commit comments

Comments
 (0)