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

[Lorenzo Pegorari <lorenzo.pegorari2002@gmail.com>]

On Mon, Mar 09, 2026 at 02:40:42PM +0100, Christian Couder wrote:
> 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