Re: rather slow 'git repack' in 'blob:none' partial clones

From: Jeff King <peff@peff.net>
Date: Apr 12, 2021, 23:51 UTC
Message-ID: <YHTc8mqqDePlrOB8@coredump.intra.peff.net>
In-Reply-To: <CAGyf7-HTCDm_SB5CfQWJWjvuCVYuJ4=h65=zG-N1XTgNRs+j0w@mail.gmail.com>

On Mon, Apr 12, 2021 at 02:49:00PM -0700, Bryan Turner wrote:

Show 7 quoted lines

> I ran into this same surprising behavior recently, too. I was adding
> some automated testing to Bitbucket for partial clones and initially
> tried to use whether the repository was configured with a partial
> clone filter as one of my checks, only to find that even when filters
> weren't supported it was still set. The only way I could find to
> detect that a partial clone that was requested didn't actually happen
> was to parse the git clone output and look for the warning.

I think the state of "we have all the objects, but things are marked as partial" is some place you could actually get into naturally: you start with a partial clone, and then later fetch the objects you need, and you just happen to have all the objects). Or you could even start there if the filter happens not to exclude any objects. So I don't think that state is invalid in any way.

But I do agree that if the client _knows_ that the filter was not used (because the other side did not advertise filters and so we did not even send it), then it is silly to create the client-side config marking us as partial. It is misleading at best, and makes things slower at worst.

-Peff