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

[Patrick Steinhardt <ps@pks.im>]

On Tue, Mar 03, 2026 at 06:00:29AM -0800, Alan Braithwaite wrote:
> Patrick wrote:
> > 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.
> 
> Thanks, this is great feedback. I took a look at the existing
> URL-based config patterns and I think the http.<url>.* model
> is the right one to follow, since it already uses the
> urlmatch_config_entry() infrastructure with proper URL
> normalization, host globs, and longest-match specificity.
> 
> Here's what I'm thinking for a v2. I'd like to get feedback
> on the design before implementing:
> 
> The config would use a new section that supports both a global
> default and per-URL overrides, following the same pattern as
> http.sslVerify vs http.<url>.sslVerify:
> 
>     # Global default — applies to all clones/fetches
>     [fetch]
>         partialCloneFilter = blob:limit=1m
> 
>     # Per-URL override — more specific match wins
>     [fetch "https://github.com/"]
>         partialCloneFilter = blob:limit=5m
> 
>     [fetch "https://internal.corp.com/"]
>         partialCloneFilter = blob:none
> 
> Design points:
> 
>   - Accepts any filter spec, not just blob:limit. This
>     addresses your point about not casting a specific filter
>     into stone.
> 
>   - Uses fetch.<url>.partialCloneFilter, following the
>     http.<url>.* precedent. The urlmatch.c infrastructure
>     handles URL normalization, host globs (*.example.com),
>     default port stripping, and path-based specificity
>     ordering — so no new matching logic would be needed.
> 
>   - A bare fetch.partialCloneFilter (no URL) acts as the
>     global default, the same way http.sslVerify is the
>     global default that http.<url>.sslVerify can override.
> 
>   - Only applies to initial clone and to fetches where no
>     existing remote.<name>.partialCloneFilter is set. Existing
>     repos continue using their per-remote config.
> 
>   - Explicit --filter on the command line still takes
>     precedence over everything.
> 
>   - If the server does not support object filtering, the
>     setting is silently ignored (existing behavior).
> 
> I chose fetch.* rather than clone.* so that both git-clone
> and git-fetch can use the same config. In practice this
> mainly matters for the initial clone, since once the promisor
> remote is registered, subsequent fetches inherit the filter
> from remote.<name>.partialCloneFilter anyway.

I think using something like "clone.<url>.defaultObjectFilter" would be
a more sensible design. The idea is that we'd only honor this filter on
the initial clone to basically be equivalent to `git clone --filter=`. I
don't think any subsequent fetches should be impacted at all, as turning
a full clone into a partial clone would need more consideration.

Patrick