The series covers functions that parse, verify and check whole objects in memory. They take sizes as "unsigned long" while callers have a size_t, so above 4GiB on Windows the size is truncated. The four patches fix check_object_signature(), where valid objects are reported as corrupt, and the fsck functions, which inspect only a prefix. They also fix the parse_*_buffer() functions, and the tag and message helpers, where "git tag -v" can miss a signature at the end of a large tag. The last one also widens an int index in copy_subject() on all platforms.
Patch 3 makes set_commit_buffer() die instead of caching a truncated size, as repo_get_commit_buffer() already does. The commit slab still stores "unsigned long" sizes. Elia says the remaining callers will be updated separately and that no tests are added because triggering the bugs needs 4GiB or more of input.
Simon Richter again reminded the author that size_t is also 32 bits on 32-bit architectures, because it is the size of in-memory objects. Data on disk can be larger and needs off_t, which is 64 bits only with large file support. He said to use size_t only for in-memory data, and that the total count when reading from disk piecewise should be an off_t.
Elia agreed. The cover letter's reference to Windows is about LLP64, where size_t is 64 bits but long is 32. This series deals only with buffers already in memory. The point prompted a v2 of the pack-objects patch, which tracks the accumulated length in write_large_blob_data().
A companion series, "use size_t when receiving and verifying packs", applies the same change to unpack-objects, index-pack and pack verification in fsck. It had no replies in the excerpts.