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

> 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.