Re: [PATCH v3 4/8] t1051: introduce a smudge filter test for extremely large files

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 2, 2021, 14:56 UTC
Message-ID: <nycvar.QRO.7.76.6.2111021542110.56@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqlf2bfmdb.fsf@gitster.g>

Hi Junio,

On Fri, 29 Oct 2021, Junio C Hamano wrote:

Show 21 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
> >> +# This smudge filter prepends 5GB of zeros to the file it checks out. This
> >> +# ensures that smudging doesn't mangle large files on 64-bit Windows.
> >> +test_expect_failure EXPENSIVE,SIZE_T_IS_64BIT,!LONG_IS_64BIT \
> >> +		'files over 4GB convert on output' '
> >> +	test_commit test small "a small file" &&
> >> +	test_config filter.makelarge.smudge \
> >> +		"test-tool genzeros $((5*1024*1024*1024)) && cat" &&
> >> +	echo "small filter=makelarge" >.gitattributes &&
> >> +	rm small &&
> >> +	git checkout -- small &&
> >> +	size=$(test_file_size small) &&
> >> +	test "$size" -ge $((5 * 1024 * 1024 * 1024))
> >> +'
> >
> > Why not exactly 5G, but anything that is at least 5G is OK?
>
> I know it is more than 5G, thanks to the "&& cat".  THe question was
> why aren't we measuring the size of "a small file" so that we can
> check against an exact size to be expected.

The main problem solved by this patch series is the fact that by virtue of using `unsigned long`, Git truncated the contents to less than 4GB. So, really, what we care about here is that that does not happen anymore.

I will change it to take the extra time to determine `small`'s file size and add that to 5GB, to avoid confusing readers, though.

Ciao, Dscho