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

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> On Sun, Mar 15, 2026 at 05:37:02AM +0000, Alan Braithwaite via GitGitGadget wrote:
>>  1:  fa1ea69bdb ! 1:  480453b2e7 clone: add clone.<url>.defaultObjectFilter config
>>      @@ t/t5616-partial-clone.sh: test_expect_success 'after fetching descendants of non
>>       +test_expect_success 'setup for clone.defaultObjectFilter tests' '
>>       +	git init default-filter-src &&
>>       +	echo "small" >default-filter-src/small.txt &&
>>      -+	dd if=/dev/zero of=default-filter-src/large.bin bs=1024 count=100 2>/dev/null &&
>>       +	git -C default-filter-src add . &&
>>       +	git -C default-filter-src commit -m "initial" &&
>>       +
>
> As Junio already pointed out, this change here is a bit puzzling. Not
> that I think it's a problem, but one wonders why this existed in the
> first place if it seemed to not be necessary.
>> ...
>> +	normalized_url = url_normalize(url, &config.url);
>> +	if (!normalized_url) {
>> +		urlmatch_config_release(&config);
>> +		return NULL;
>> +	}
>
> We haven't allocated anything, right? So in theory, we should be able to
> return early without calling `urlmatch_config_release()`. This could be
> stressed further by moving the error path earlier, so that it's the
> first thing we do in the function.


We haven't heard any response to these points raised in the message
I am responding to.  Should I still keep the patch in my tree,
hoping that a responses may come some day?  I am tempted to discard
the topic as it has been quite a while since we last looked at it.

Thanks.