Re: [PATCH 6/6] t5608: add regression test for >4GB object clone

From: Derrick Stolee <stolee@gmail.com>
Date: Apr 29, 2026, 13:34 UTC
Message-ID: <e1e8837f-7374-4079-ba87-ab95dd156e33@gmail.com>
In-Reply-To: <a3019888d8465e0f77926a91a20db170fef6989d.1777393580.git.gitgitgadget@gmail.com>

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

Show 10 quoted lines

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> The shift overflow bug in index-pack and unpack-objects caused incorrect
> object size calculation when the encoded size required more than 32 bits
> of shift. This would result in corrupted or failed unpacking of objects
> larger than 4GB.
> 
> Add a test that creates a pack file containing a 4GB+ blob using the
> new 'test-tool synthesize pack --reachable-large' command, then clones
> the repository to verify the fix works correctly.

As mentioned in the previous patch, constructing this large packfile takes ~4 minutes in CI pipelines. That's quite a lot to handle for every CI run.

> +test_expect_success SIZE_T_IS_64BIT 'set up repo with >4GB object' '

Your prereq here prevents it from running on 32-bit builds, which is good. However, I wonder if it would be worth also specifying these tests as expensive. It's less likely that these layers will be touched often, so it should be enough to run these on major occasions, such as testing a release candidate.

(I also think it's appropriate to have these tests _not_ be marked expensive in their original contribution to git-for-windows/git, because the pull request build should prove that the tests work. And maybe git-for-windows/git should keep them for every PR since that's where the tests matter the most.)

I suppose this also is a question for Junio and our process for validating releases. Do we have a certain cadence where we run the expensive tests? What has been our threshold for hiding a test case behind the expensive label?

Thanks, -Stolee