Advertising

So why isn't the patch much more straightforward? Like the attached
totally untested one that just limits the read/write size to 8MB
(which is totally arbitrary, but small enough to not have any latency
issues even on slow disks, and big enough that any reasonable IO
subsystem will still get good throughput).

Ahh. OK, not noticing EINVAL unconditionally, but always feed IOs
in chunks that are big enough for sane systems but small enough for
broken ones.
That makes sense. Could somebody on MacOS X test this?

I tested this on both i386 (OS X 32-bit intel) and x86_64 (OS X 64-bit
intel).

The size 2147487744 is 2GB + 4096 bytes. Apparently git does not
support a filter for a file unless the file can fit entirely into
git's memory space. Normally a single 2GB + 4096 byte allocation
works in an OS X 32-bit process, but something else is apparently
eating up a large portion of the memory space in this case (perhaps an
mmap'd copy?). In any case, if the file being filtered was closer to
4GB in size it would always fail on 32-bit regardless.

The fact that the entire file is read into memory when applying the
filter does not seem like a good thing (see #7-#10 above).