Re: [PATCH] fetch, clone: add fetch.blobSizeLimit config

From: Patrick Steinhardt <ps@pks.im>
Date: Mar 3, 2026, 06:30 UTC
Message-ID: <aaaACBJVAZPypVtn@pks.im>
In-Reply-To: <a3e064fe-9f0d-448f-b034-4a95dcd3fe97@app.fastmail.com>

On Mon, Mar 02, 2026 at 01:36:40PM -0800, Alan Braithwaite wrote:

Show 10 quoted lines

> Peff wrote:
> > We actually can do blob:limit filters with bitmaps. See
> > 84243da129 (pack-bitmap: implement BLOB_LIMIT filtering,
> > 2020-02-14).
> 
> Good to know. I'm not positive, but my understanding is that
> this patch only touches client code, and the server sees an
> identical request to what `git clone --filter=blob:limit=1m`
> already sends today. If that's correct, anyone can already
> impose that cost — this patch just makes it easier to opt in.

Ah, right, that's something I forgot. I've seen too many performance issues recently with blob:limit fetches, so I jumped the gun.

Show 13 quoted lines

> Junio wrote:
> > As to this extra variable, it can already be done with
> > existing remote.*.partialCloneFilter, it seems, so I do not
> > know why we want to add it.
> 
> I may not understand the config as well as you do, but my
> reading is that remote.*.partialCloneFilter requires a specific
> remote name and only takes effect on subsequent fetches from an
> already-registered promisor remote — not the initial clone. You
> would also need remote.origin.promisor=true set globally, which
> seems odd. If I'm understanding correctly, there is currently
> no way to say "all new clones should use a blob size filter"
> via config alone. But please correct me if I'm wrong.

No, you're right about this one, and I think this is a sensible thing to want. But what I'd like to see is a bit more nuance, I guess:

  - It should be possible to specify the configuration per URL. If you
    know that git.example.com knows object filters you may want to turn
    them on for that domain specifically. So the mechanism would work
    similar to "url.<base>.insteadOf" or "http.<url>.*" settings.

  - The infrastructure shouldn't cast any specific filter into stone.
    Instead, it should be possible to specify a default filter.

I'd assume that these settings should only impact the initial clone to use a default filter in case the cloned URL matches the configured URL. For existing repositories it shouldn't have any impact, as we should continue to respect the ".git/config" there when it comes to promisors and filters.

> Separately — is my understanding correct that partial clone
> with blob:limit works today without server-side changes,
> assuming uploadpack.allowFilter is enabled? If so, I'm happy
> to maintain this as a local client patch for my own workflow.

Yes, blob:limit filters are supported by many forges nowadays.

Patrick