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
