From: Patrick Steinhardt Date: Mon, 11 May 2026 07:30:19 GMT Subject: Re: [PATCH v6] clone: add clone..defaultObjectFilter config Message-ID: In-Reply-To: On Mon, May 11, 2026 at 11:38:15AM +0900, Junio C Hamano wrote: > 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. It's been a while indeed. I'd say we can discard it for now, as we can easily add it back in at a later point in time once the next version is posted. Patrick