[Outreachy PATCH] doc: clarify promisor remote fetch ordering

[Outreachy PATCH] doc: clarify promisor remote fetch ordering

[Wasswa Edson]

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

Signed-off-by: Edson <edsonwasswa54@gmail.com>
---
 Documentation/technical/partial-clone.adoc | 5 +++++
 1 file changed, 5 insertions(+)

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.

 Remotes that are considered "promisor" remotes are those specified by
 the following configuration variables:
--
2.53.0

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

[Junio C Hamano]

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.

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

[Wasswa Edson]

Thanks so much about that but if i look into the codebase, Your
concern is valid from a security perspective, but the implementation
already has safeguards that prevent arbitrary injection
Then about the Git server my say is a No, coz a server cannot
arbitrarily inject a brand-new, untrusted promisor remote onto a
client by default. The client must explicitly configure acceptance
policies before any server-advertised remote will be accepted.
If I am wrong let me be guided.
I am re-doing the patch again following the doc you have provided
Thank you

On Thu, 22 Oct 2026 at 20:35, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.
>

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

[Junio C Hamano]

Wasswa Edson <edsonwasswa54@gmail.com> writes:

> ... the implementation
> already has safeguards that prevent arbitrary injection
> Then about the Git server my say is a No, coz a server cannot
> arbitrarily inject a brand-new, untrusted promisor remote onto a
> client by default. The client must explicitly configure acceptance
> policies before any server-advertised remote will be accepted.

An explanation like the above must be in your proposed log message
so that the next person who looks at your patch do not have to ask
the same question.

Also, we frown upon top-posting on this list.

Thanks.