Re: [PATCH v4] clone: do faster object check for partial clones

From: Jeff King <peff@peff.net>
Date: Apr 22, 2019, 21:31 UTC
Message-ID: <20190422213113.GB4728@sigill.intra.peff.net>
In-Reply-To: <b4a285e2a199ea059c165aa344d037374797fa40.1555707373.git.steadmon@google.com>

On Fri, Apr 19, 2019 at 02:00:13PM -0700, Josh Steadmon wrote:

Show 14 quoted lines

> 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 <steadmon@google.com>
> ---
> 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