From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 03 Mar 2026 17:05:30 GMT
Subject: Re: [PATCH] fetch, clone: add fetch.blobSizeLimit config
Message-ID: <xmqqseagetd1.fsf@gitster.g>
In-Reply-To: <aaaACBJVAZPypVtn@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

> No, you're right about this one, and I think this is a sensible thing to
> want. But what I'd like to see is a bit more nuance, I guess:
>
>   - It should be possible to specify the configuration per URL. If you
>     know that git.example.com knows object filters you may want to turn
>     them on for that domain specifically. So the mechanism would work
>     similar to "url.<base>.insteadOf" or "http.<url>.*" settings.
>
>   - The infrastructure shouldn't cast any specific filter into stone.
>     Instead, it should be possible to specify a default filter.
>
> I'd assume that these settings should only impact the initial clone to
> use a default filter in case the cloned URL matches the configured URL.
> For existing repositories it shouldn't have any impact, as we should
> continue to respect the ".git/config" there when it comes to promisors
> and filters.

Ahh, thanks for pointing out the flaw in my thinking that forgets
that "remote.<name>.partialCloneFilter" would not work in the
initial state where there is no <name> associated with the remote
repository you are trying to contact.  I agree that something like
"remote.<url>.particialCloneFilter" is a more proper way forward.