Christian Couder <christian.cou...@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?
