Re: [GSoC] extensions.partialClone and promisor remote fetch order
- From
Lorenzo Pegorari <lorenzo.pegorari2002@gmail.com>
- Date
- Mar 10, 2026, 18:32 UTC
- Message-ID
- <abBjzBFDReUnIvdK@lorenzo-VM>
- In-Reply-To
- <CAP8UFD1cQHUzxu0cWjVWBfBWh8qOy2+oOb0rwo5CmgJ2qKRFDA@mail.gmail.com>
On Mon, Mar 09, 2026 at 02:40:42PM +0100, Christian Couder wrote:
Show 40 quoted lines
> Hi Lorenzo, > > On Sat, Mar 7, 2026 at 10:28 AM Lorenzo Pegorari > <lorenzo.pegorari2002@gmail.com> wrote: > > > > 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. > > > 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. > > > 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.
Exactly what I thought. Thanks for the clarifications Christian!
I just sent my GSoC'26 proposal, where I took into consideration this discussion: https://lore.kernel.org/git/abBh__zmlWXY-yjI@lorenzo-VM/
Lorenzo