Re: [PATCH] fetch, clone: add fetch.blobSizeLimit config
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Mar 3, 2026, 15:08 UTC
- Message-ID
- <aab5iICOAMrH2aQZ@pks.im>
- In-Reply-To
- <d4e2aa7e-6c6e-43a5-96ad-848d9447d194@app.fastmail.com>
On Tue, Mar 03, 2026 at 06:00:29AM -0800, Alan Braithwaite wrote:
Show 70 quoted lines
> 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