Elia Pinto's series differs from earlier ones in that it does not concern "long" being 32 bits on Windows. The types involved (uint32_t, int, unsigned int) are 32 bits on every platform. The cases came from scanning a native 64-bit Linux build with -Wshorten-64-to-32, which also sees conversions from unsigned long that a Windows target cannot.
Patch 1 changes the count parameter of hashwrite() to size_t. If pack-objects writes a compressed buffer of 4GiB or more in a single call, only count mod 2^32 bytes are written, corrupting the pack. This needs an in-memory, poorly compressible object with core.bigFileThreshold raised accordingly.
Patch 2 makes the size parameter of count_lines() a size_t. For files of 2GiB or more the int goes negative or truncates, giving a wrong "git diff -B --stat" line count. The author says there are no memory-access issues.
Patch 3 changes hash_chars() in diffcore-delta.c. With a file of 4GiB or more it hashes only a prefix, which understates similarity and misses true renames, including in "git log --follow" and merges.
There are no tests, since triggering the bugs needs huge inputs. Each fix was checked by simulating the truncation at 16 bits. Pinto has also posted related series on pack-objects, grep and diff, archive and apply, and a binary-hunk size check in apply. No review replies appear in the excerpts.