From: "Alan Braithwaite" <alan@braithwaite•dev>
To: "Patrick Steinhardt" <ps@pks•im>
Cc: "Junio C Hamano" <gitster@pobox•com>,
"Alan Braithwaite" <gitgitgadget@gmail•com>,
git@vger•kernel.org, christian.couder@gmail•com,
jonathantanmy@google•com, me@ttaylorr•com
Subject: Re: [PATCH] fetch, clone: add fetch.blobSizeLimit config
Date: Tue, 03 Mar 2026 06:00:29 -0800 [thread overview]
Message-ID: <d4e2aa7e-6c6e-43a5-96ad-848d9447d194@app.fastmail.com> (raw)
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
next prev parent reply other threads:[~2026-03-03 14:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-01 16:44 [PATCH] fetch, clone: add fetch.blobSizeLimit config Alan Braithwaite via GitGitGadget
2026-03-02 11:53 ` Patrick Steinhardt
2026-03-02 18:28 ` Jeff King
2026-03-02 18:57 ` Junio C Hamano
2026-03-02 21:36 ` Alan Braithwaite
2026-03-03 6:30 ` Patrick Steinhardt
2026-03-03 14:00 ` Alan Braithwaite [this message]
2026-03-03 15:08 ` Patrick Steinhardt
2026-03-03 17:58 ` Junio C Hamano
2026-03-04 5:07 ` Patrick Steinhardt
2026-03-03 17:05 ` Junio C Hamano
2026-03-03 14:34 ` Jeff King
2026-03-05 0:57 ` [PATCH v2] clone: add clone.<url>.defaultObjectFilter config Alan Braithwaite via GitGitGadget
2026-03-05 19:01 ` Junio C Hamano
2026-03-05 23:11 ` Alan Braithwaite
2026-03-06 6:55 ` [PATCH v3] " Alan Braithwaite via GitGitGadget
2026-03-06 10:39 ` brian m. carlson
2026-03-06 19:33 ` Junio C Hamano
2026-03-06 21:50 ` Alan Braithwaite
2026-03-06 21:47 ` [PATCH v4] " Alan Braithwaite via GitGitGadget
2026-03-06 22:18 ` Junio C Hamano
2026-03-07 1:04 ` Alan Braithwaite
2026-03-07 1:33 ` [PATCH v5] " Alan Braithwaite via GitGitGadget
2026-03-11 7:44 ` Patrick Steinhardt
2026-03-15 1:33 ` Alan Braithwaite
2026-03-15 5:37 ` [PATCH v6] " Alan Braithwaite via GitGitGadget
2026-03-15 21:32 ` Junio C Hamano
2026-03-16 7:47 ` Patrick Steinhardt
2026-05-11 2:38 ` Junio C Hamano
2026-05-11 7:30 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d4e2aa7e-6c6e-43a5-96ad-848d9447d194@app.fastmail.com \
--to=alan@braithwaite$(echo .)dev \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=jonathantanmy@google$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox