From: Alan Braithwaite <alan@braithwaite.dev>
Date: Tue, 03 Mar 2026 14:00:29 GMT
Subject: Re: [PATCH] fetch, clone: add fetch.blobSizeLimit config
Message-ID: <d4e2aa7e-6c6e-43a5-96ad-848d9447d194@app.fastmail.com>
In-Reply-To: <aaaACBJVAZPypVtn@pks.im>

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.

Does this direction make sense? Happy to hear if there are
concerns before I start on a v2.

Thanks,
- Alan