From: Junio C Hamano Date: Mon, 11 May 2026 02:38:15 GMT Subject: Re: [PATCH v6] clone: add clone..defaultObjectFilter config Message-ID: In-Reply-To: Patrick Steinhardt writes: > On Sun, Mar 15, 2026 at 05:37:02AM +0000, Alan Braithwaite via GitGitGadget wrote: >> 1: fa1ea69bdb ! 1: 480453b2e7 clone: add clone..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.