Re: [PATCH v2 00/36] Promisor remotes and external ODB support

Christian Couder [off-list ref] writes:

A lot of things are different because the jh/fsck-promisors and
jh/partial-clone have been merged into master since the v1. So the
integration is much more complete now (though not fully complete), and
this integration happens quite early in the patch series.

This integration makes it possible to have many promisor and partial
clone remotes (instead of just one) with possibly different partial
clone filters, though that is not tested yet.

I am not sure that the "external odb" name is still the best, as the
promisor remotes are not quite external. So I am open to suggestions
about a new name.

So,... so far we have a way to make an incomplete clone of a project
from a remote that promises that objects (deliberately) missing from
the resulting repository are available later by an on-demand request.

We do not yet have code to actually make an on-demand request, and
the other side of the request to fulfill the promise.  

And that is what these patches want to do?

That sounds like a "lazy backfill" mechanism; I know others are
better in naming things than me, though ;-)

On the other hand, if the code updated with these patches do not
cooperate with the promise mechansim (e.g. request is made to any
missing objects, instead of "this object was promised by that
remote, so let's go there and ask" and "this object is simply
missing, without promise by anybody, so let's not bother the
promisor remote"), then it is not even "back"-filling, but is a
mechanism to access remote object database over a protocol, so
a minimum s/ext/remote/ would clarify what it is.

I guess "lazy backfill" would be more preferrable than a pile of
independent, competing and uncooperative features ;-)

  - Patches 13/36 and 14/36:

These patches move over the promisor objects and partial clone code to
use the external odb mechanism. The result of 13/36 is that instead of
the "extensions.partialclone" config variable, a
"odb.<name>.promisorRemote" config variable is now used. The result of
14/36 is that instead of the "core.partialclonefilter" config
variable, a "odb.<name>.partialclonefilter" config variable is now
used.

The use of "extensions" was to protect the repository from versions
of Git that are unaware of the "promise" mechanism to even attempt
touching it.  Will we keep the same degree of safety with these
changes, I wonder?