Re: [PATCH v4] clone: add clone.<url>.defaultObjectFilter config
- From
- Alan Braithwaite <alan@braithwaite.dev>
- Date
- Mar 7, 2026, 01:04 UTC
- Message-ID
- <01215e9c-c110-4860-a285-7f09bc6596e5@app.fastmail.com>
- In-Reply-To
- <xmqqfr6cy53q.fsf@gitster.g>
Thanks for the careful review, Junio. You're right on both counts. The stale commit message and the test style were sloppy oversights that I should have caught before resubmitting.
I'll be more disciplined about reviewing the full diff (including the commit message) against the actual behavior for future patches. Thanks for helping out on my first patch.
The updated incoming patch addresses both issues: the commit message now accurately describes the bare and URL-qualified forms, and all tests use the test_cmp pattern. I'll be submitting what I think should be the final version shortly, but I'm happy to continue iterating if anything else looks concerning.
Thanks, - Alan
On Fri, Mar 6, 2026, at 14:18, Junio C Hamano wrote:
Show 71 quoted lines
> "Alan Braithwaite via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: Alan Braithwaite <alan@braithwaite.dev> >> >> Add a new configuration option that lets users specify a default >> partial clone filter per URL pattern. When cloning a repository >> whose URL matches a configured pattern, git-clone automatically >> applies the filter, equivalent to passing --filter on the command >> line. >> >> [clone "https://github.com/"] >> defaultObjectFilter = blob:limit=5m >> >> [clone "https://internal.corp.com/large-project/"] >> defaultObjectFilter = blob:none >> >> URL matching uses the existing urlmatch_config_entry() infrastructure, >> following the same rules as http.<url>.* — you can match a domain, >> a namespace path, or a specific project, and the most specific match >> wins. >> >> The config only affects the initial clone. Once the clone completes, >> the filter is recorded in remote.<name>.partialCloneFilter, so >> subsequent fetches inherit it automatically. An explicit --filter >> flag on the command line takes precedence. >> >> Only the URL-qualified form (clone.<url>.defaultObjectFilter) is >> honored; a bare clone.defaultObjectFilter without a URL subsection >> is ignored. > > Is this still valid? It is inconsistent with the updated > documentation where both clone.defaultObjectFilter and > clone.<url>.defaultObjectFilter are listed. > > These iterations of patches may require a bit more careful > proofreading before getting sent to the mailing list for others to > comment on, I suspect? > >> Signed-off-by: Alan Braithwaite <alan@braithwaite.dev> >> --- >> ... >> +`clone.defaultObjectFilter`:: >> +`clone.<url>.defaultObjectFilter`:: >> + When set to a filter spec string (e.g., `blob:limit=1m`, >> + `blob:none`, `tree:0`), linkgit:git-clone[1] will automatically >> + use `--filter=<value>` to enable partial clone behavior. >> + Objects matching the filter are excluded from the initial >> + transfer and lazily fetched on demand (e.g., during checkout). >> + Subsequent fetches inherit the filter via the per-remote config >> + that is written during the clone. >> ++ >> +The bare `clone.defaultObjectFilter` applies to all clones. The >> +URL-qualified form `clone.<url>.defaultObjectFilter` restricts the >> +setting to clones whose URL matches `<url>`, following the same >> +rules as `http.<url>.*` (see linkgit:git-config[1]). The most >> +specific URL match wins. You can match a domain, a namespace, or a >> +specific project: > > > In the test script we see a handful of lines like these > >> + test "$(git -C default-filter-blobnone config --local remote.origin.promisor)" = "true" && >> + test "$(git -C default-filter-blobnone config --local remote.origin.partialclonefilter)" = "blob:none" > > added. They may have been written to mimick an existing line in a > test elsewhere, but see efforts by others like > > > https://lore.kernel.org/git/20260305225128.54283-1-francescopaparatto@gmail.com/ > > Thanks.