From: Christian Couder Date: Mon, 09 Mar 2026 13:40:42 GMT Subject: Re: [GSoC] extensions.partialClone and promisor remote fetch order Message-ID: In-Reply-To: Hi Lorenzo, On Sat, Mar 7, 2026 at 10:28 AM Lorenzo Pegorari 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..promisor" and "remote..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.