[PATCH v2] doc: describe promisor remote fetch order

[Hussain Sitamouwala <husainsitamuwala21@gmail.com>]

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 <husainsitamuwala21@gmail.com>
---
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()

 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:
-- 
2.53.0