Re: [PATCH v2] doc: describe promisor remote fetch order

[Junio C Hamano <gitster@pobox.com>]

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

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.

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