Re: [PATCH 0/6] Handle cloning of objects larger than 4GB on Windows

From: Derrick Stolee <stolee@gmail.com>
Date: Apr 29, 2026, 13:35 UTC
Message-ID: <7bed56a9-520c-4d7b-a4d6-f03d89667993@gmail.com>
In-Reply-To: <pull.2102.git.1777393580.gitgitgadget@gmail.com>

On 4/28/26 12:26 PM, Johannes Schindelin via GitGitGadget wrote:

Show 14 quoted lines

> 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.

Show 5 quoted lines

> 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