git client erroneously downloads files when --filter=blob:none and filtering unsupported

> The git client, in my opinion, erroneously downloads files when
> --filter=blob:none is specified and the server does not support
> filtering. I created a related question on this before coming here:
> 
> https://stackoverflow.com/q/79413099/15534181
> 
> Instead of giving a warning, it should instead error and exit. From a
> user perspective, when I request "don't pull down the file contents"
> and it does it anyway under some circumstances, this is unexpected. In
> my case it caused performance degradations on a repo scanner.
> 
> I propose something like this:
> 
> https://github.com/jagprog5/git/commit/c4bd8c9640c1491dc6e23acf31fa0230485b68b1
> 
> This is not backwards compatible. My question is, how best should this
> be handled?  Is this breaking change ok? Or should there instead be a
> new CLI arg or config which enabled this new behaviour. Looking for
> advice, thanks.

>
> On Sat, Feb 22, 2025 at 10:01:22AM -0500, John Giorshev wrote:
>
> > The git client, in my opinion, erroneously downloads files when
> > --filter=blob:none is specified and the server does not support
> > filtering. I created a related question on this before coming here:
> >
> > https://stackoverflow.com/q/79413099/15534181
> >
> > Instead of giving a warning, it should instead error and exit. From a
> > user perspective, when I request "don't pull down the file contents"
> > and it does it anyway under some circumstances, this is unexpected. In
> > my case it caused performance degradations on a repo scanner.
> >
> > I propose something like this:
> >
> > https://github.com/jagprog5/git/commit/c4bd8c9640c1491dc6e23acf31fa0230485b68b1
> >
> > This is not backwards compatible. My question is, how best should this
> > be handled?  Is this breaking change ok? Or should there instead be a
> > new CLI arg or config which enabled this new behaviour. Looking for
> > advice, thanks.
>
> I could see arguments going either way:
>
>   - you asked for no blobs, but it's just an optimization, so we can
>     complete the operation for a bit more expense. It should be a
>     warning. That makes it safe just sprinkle "--filter=blob:none"
>     wherever you like, and sometimes things get faster and sometimes
>     not.
>
>   - downloading the blobs is so expensive that it's better to fail than
>     spend resources on something that will probably fail eventually
>     anyway.
>
> Which implies to me it should perhaps be configurable. And then that
> gives you a backwards-compatibility solution, too. Step 1 is to add the
> config. Step 2 may eventually be to flip the default, and there the
> config option gives people an escape hatch if they like the old
> behavior.
>
> All that said, I wondered if there was another similar case: when the
> server supports filters but your particular filter is not allowed.
>
> E.g., if the server has config like this:
>
>   [uploadpackfilter "blob:none"]
>   allow = false
>
> But then interestingly, we already consider that a fatal error!
>
>   $ git clone --filter=blob:none --no-local /path/to/repo
>   fatal: filter 'blob:none' not supported
>   fatal: remote error: filter 'blob:none' not supported
>
> So I dunno. Maybe nobody actually cares about continuing with a warning
> for this case. OTOH, I doubt anybody would forbid _just_ blob:none; it's
> the cheapest filter to support. So it's likely that nobody has run into
> it. But the behavior would be the same with something like sparse:oid,
> which is likely to be forbidden because it's expensive. So:
>
>   $ git clone --filter=sparse:oid=foo https://github.com/git/git
>   Cloning into 'git'...
>   fatal: remote error: filter 'sparse:oid' not supported
>
> Which maybe implies that worrying about config or backwards
> compatibility is not worth it.
>
> -Peff