From: Derrick Stolee Date: Wed, 29 Apr 2026 13:35:54 GMT Subject: Re: [PATCH 0/6] Handle cloning of objects larger than 4GB on Windows Message-ID: <7bed56a9-520c-4d7b-a4d6-f03d89667993@gmail.com> In-Reply-To: On 4/28/26 12:26 PM, Johannes Schindelin via GitGitGadget wrote: > On Windows, unsigned long is 32-bit even on 64-bit systems. This causes > multiple problems when Git handles objects larger than 4GB. This patch > series is a very targeted fix for a very early part of the problem: it > addresses the most fundamental truncation points that prevent a >4GB object > from surviving a clone at all. > > Specifically, this fixes: > > * zlib's uLong wrapping and triggering BUG() assertions in the git_zstream > wrapper > * Object sizes being truncated in pack streaming, delta headers, and > index-pack/unpack-objects > * pack-objects re-encoding reused pack entries with a truncated size, > producing corrupt packs on the wire I'm glad to see this progress in this direction. It's a big step! > Many other code paths still use unsigned long for object sizes (e.g., > cat-file -s, object_info.sizep, the delta machinery) and will need their own > conversions. This series does not attempt to fix those. I appreciate the mechanisms used to keep the scope of change minimal. This differs from the typical "replace all 'unsigned long's with 'size_t'" proposals in some clever ways. > Based on work by @LordKiRon in git-for-windows/git#6076. > > The last two commits add a test helper that synthesizes a pack with a >4GB > blob and regression tests that clone it via both the unpack-objects and > index-pack code paths using file:// transport. My biggest concern here is about how expensive this test is. I wonder if we should mark it as expensive for the core project and leave it enabled by default in git-for-windows/git. Thanks, -Stolee