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

[Jeff King <peff@peff.net>]

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

> 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