Re: [GSoC] extensions.partialClone and promisor remote fetch order

From: Christian Couder <christian.couder@gmail.com>
Date: Mar 9, 2026, 13:40 UTC
Message-ID: <CAP8UFD1cQHUzxu0cWjVWBfBWh8qOy2+oOb0rwo5CmgJ2qKRFDA@mail.gmail.com>
In-Reply-To: <aavvwfZllMWUwIl3@lorenzo-VM>

Hi Lorenzo,

On Sat, Mar 7, 2026 at 10:28 AM Lorenzo Pegorari <lorenzo.pegorari2002@gmail.com> wrote:

Show 7 quoted lines

>
> Hi everyone. In the past weeks I deeply studied the documentation
> regarding the GSoC'26 idea "Implement promisor remote fetch ordering". I
> am preparing a proposal that is as detailed as possible, and that tries
> to answer to as many questions as possible. I am also experimenting a
> lot with multiple promisor remotes configurations, and creating some
> examples that I will showcase in my proposal.

Thanks for your interest in Git and this project.

Show 13 quoted lines

> I have a question regarding the interaction between the config
> "extensions.partialClone" and a possible fetch ordering mechanism:
>  * from my understanding, and from my personal tests, it looks like
>    "extensions.partialClone" is not essential when working with multiple
>    promisor remotes. Having these promisor remotes setted up with
>    "remote.<name>.promisor" and "remote.<name>.partialCloneFilter" seems
>    sufficient. In this case, the promisor remotes will be tried one
>    after the other, in the order in which they appear in the config.
>  * if "extensions.partialClone" is present, then the promisor remote
>    configured using the "extensions.partialClone" config var will be the
>    last one tried when fetching an object.
>
> 1. is what I explained correct?

Yes, I think so. The "Using many promisor remotes" section of "Documentation/technical/partial-clone.adoc" seems to agree with what you say.

Show 5 quoted lines

> 2. when the fetch ordering mechanism will be added, this config var will
>    not be useful anymore. How should it be handled? It probably can't
>    just be removed, so the fetch ordering mechanism should be flexible
>    enough to handle a situation where "extensions.partialClone" is
>    present, correct?

Yes, for backward compatibility, it's better to have things work as they used to when the new ordering mechanism is not used.