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).
Signed-off-by: Hussain Sitamouwala <redacted>
---
Changes since v1:
- shortened the subject and wrapped the commit message
- clarified what "accepted" means and the fetch fallback wording
- checked the wording against try_promisor_remotes()
Please thread your patches correctly.
This message, which sends the v2 iteration of the patch, should be a
reply to your v1. However, there is no In-Reply-To (or References)
header linking this message to the message that contained the v1
iteration. This hurts automation.
Also, it is not considered good manners to send a new iteration
before first finishing the discussion on the reviews you received on
your previous iteration. You respond to reviews, saying "I will fix
this point", "I think this one is fine as-is because...", and so
forth, wait for responses to your response, and eventually come to
an agreement with those in the discussion. Only after finishing all
of that do you prepare and send a new iteration.
Thanks.
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.
Remotes that are considered "promisor" remotes are those specified by
the following configuration variables: