Hussain Sitamouwala [off-list ref] writes:
Explain that promisor remotes accepted from a server are tried
before other promisor remotes, and that the remaining objects are
requested from the next remote when a fetch fails. The ordering
was introduced by 8808e61fd3 (promisor-remote: try accepted
remotes before others in get_direct(), 2026-04-07).
Well written. "next" sounded a bit strange thing to say in the
context, but it was understandable.
Assuming that I understood what the author wanted to say correctly,
that is ;-), so let's double-check. Would it mean the same thing if
we replace "next remote" with "other promisor remotes"?
quoted hunk ↗ jump to hunk
Documentation/technical/partial-clone.adoc | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/partial-clone.adoc b/Documentation/technical/partial-clone.adoc
index 18718a3840..efe9acac65 100644
--- a/Documentation/technical/partial-clone.adoc
+++ b/Documentation/technical/partial-clone.adoc
@@ -195,7 +195,10 @@ cache servers for fetching missing blobs while continuing to do
filtered `git-fetch` commands from the central server.
When fetching objects, promisor remotes are tried one after the other
-until all the objects have been fetched.
+until all the objects have been fetched. Promisor remotes that the
+client accepted from a server's advertisement are tried before the
+other promisor remotes. If a fetch from a remote fails, the objects
+that are still missing are requested from the next remote.
The same comment on "next" here.