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

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> 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?