Junio C Hamano wrote: > Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: >> Jonathan Nieder wrote: >>> [object] >>> missingObjectRemote = local-cache-remote >>> missingObjectRemote = origin >> >> In the presence of missingObjectRemote, old versions of Git, when lazily >> fetching, would only know to try the extensions.partialClone remote. But >> this is safe because existing data wouldn't be clobbered (since we're >> not using ideas like adding meaning to the contents of the .promisor >> file). Also, other things like fsck and gc still work. > > It is a good idea to implicitly include the promisor-remote to the > set of secondary places to consult to help existing versions of Git, > but once the repository starts fetching incomplete subgraphs and > adding new object.missingobjectremote [*1*], these versions of Git > will stop working correctly, so I am not sure if it is all that > useful approach for compatibility in practice. Can you spell this out for me more? Do you mean that a remote from this list might make a promise that the original partialClone remote can't keep? If we're careful to only page in objects that were promised by the original partialClone remote, then a promise "I promise to supply you on demand with any object directly or indirectly reachable from any object you have fetched from me" from the partialClone remote should be enough. > [Footnote] > > *1* That name with two "object" in it sounds horrible. Sorry about that. Another name used while discussing this was objectAccess.promisorRemote. As long as the idea is clear (that this means "remotes to use when attempting to obtain an object that is not already available locally"), I am not attached to any particular name. Thanks, Jonathan
