On Fri, Apr 19, 2019 at 02:00:13PM -0700, Josh Steadmon wrote:
> For partial clones, doing a full connectivity check is wasteful; we skip
> promisor objects (which, for a partial clone, is all known objects), and
> enumerating them all to exclude them from the connectivity check can
> take a significant amount of time on large repos.
>
> At most, we want to make sure that we get the objects referred to by any
> wanted refs. For partial clones, just check that these objects were
> transferred.
>
> Signed-off-by: Josh Steadmon <[email protected]>
> ---
> This is an update of the original V1 approach (skipping the fully
> connectivity check when doing a partial clone) with updated commit
> message and comments to address the review concerns.
This looks OK to me. Just trying to think of ways it could bite us, the
obvious line of thinking is where "--reference" is used. If we tell the
other side we already have object X, it will not be sent to us, and we
are relying on our local non-promisor alternate to have all of the
required objects. But I think this is OK:
- for it to be mentioned in a ref, then the server must have been
advertising it. Which means that it should similarly be on the hook
for providing it to us via the promisor mechanism. That's a little
hand-wavy, but then so is the entire promisor concept. We're
inherently at the server's mercy, so if they're lying to us about
what they're willing or able to provide, there's not much we can do
anyway.
- if we sent it as a "have" to the server, that means that our
alternate was advertising it from a ref tip. Which means that unless
it's corrupted, we're fine (which is no different than the
connectivity promise we'd make for our own refs). I actually think
that the connectivity check should "--not" any advertised alternate
tips. I even have a patch to do that, but I need to polish it a
little.
So I think this optimization will yield correct results. If we later
figure out a better way for rev-list to optimize this case itself, then
we can rip this out.
I think you had dug up some numbers to put in the commit message after
the last discussion? Likewise, is there a t/perf test which shows this
off (and will help us catch regressions)? If not, it might be worth
adding one (AFAICT a simple no-blobs partial-clone would be enough).
-Peff
