Re: [Outreachy PATCH] doc: clarify promisor remote fetch ordering

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

Wasswa Edson <edsonwasswa54@gmail.com> writes:

> From fe5f35b00eafa1eb2756178445d3e88c4e9d6787 Mon Sep 17 00:00:00 2001
> From: Edson <edsonwasswa54@gmail.com>
> Date: Thu, 22 Oct 2026 13:09:21 +0300
> Subject: [PATCH] doc: clarify promisor remote fetch ordering

None of the above should be included in the e-mailed patch.  Your
MUA would record your name in the "From:" header, the commit title
in the "Subject:" header, and the date when the public first saw
this contribution from you in the "Date:" header, which should
become the author date recorded in the project history.

On the other hand, there needs to be an explanation to convince
the project that it should want this change before your sign-off.

> Signed-off-by: Edson <edsonwasswa54@gmail.com>

See Documentation/SubmittingPatches [[dco]] and [[real-name]].

> diff --git a/Documentation/technical/partial-clone.adoc
> b/Documentation/technical/partial-clone.adoc
> index 18718a3840..a1104930fb 100644
> --- a/Documentation/technical/partial-clone.adoc
> +++ b/Documentation/technical/partial-clone.adoc
> @@ -196,6 +196,11 @@ 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.
> +When a server advertises promisor remotes via the protocol v2
> +"promisor-remote" capability and the client accepts them (see
> +linkgit:gitprotocol-v2[5]), those accepted remotes are tried first.
> +After trying the accepted remotes, Git then tries the other configured
> +promisor remotes as described below.

Just fact checking.

I thought that a remote Git server cannot arbitrarily inject,
advertise, or force a brand-new, untrusted promisor remote config
onto a client during a protocol exchange (such as a standard git
fetch or git clone) if the client doesn't already have it configured
locally.  But the above description makes it sound as if the server
can advertise a remote repository that the client does not know or
care about and direct the client to go there first.  Is that true
(yes, I am wondering if there is a security implication around
here)?

Thanks.