Subject: Re: [PATCH v4] clone: add clone.<url>.defaultObjectFilter config

From: "Alan Braithwaite" <[email-masked]>
Date: Fri, 06 Mar 2026 17:04:36 -0800

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:
> "Alan Braithwaite via GitGitGadget" <[email-masked]> writes:
>
>> From: Alan Braithwaite <[email-masked]>
>>
>> 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 <[email-masked]>
>> ---
>> ...
>> +`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/[email-masked]/
>
> Thanks.