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

From: Jeff King <peff@peff.net>
Date: Feb 25, 2025, 01:32 UTC
Message-ID: <20250225013227.GB752084@coredump.intra.peff.net>
In-Reply-To: <CADJmAEiE=9Ar8CJFRWeN9f0i7TVDOF7VcV+4f-UaPw0m6Frh6w@mail.gmail.com>

On Sat, Feb 22, 2025 at 10:01:22AM -0500, John Giorshev wrote:

Show 19 quoted lines

> 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