Subject: Re: [PATCH v2 2/2] Prevent git from rehashing 4GiB files

From: Junio C Hamano <[email-masked]>
Date: Thu, 12 Oct 2023 15:11:39 -0700

"brian m. carlson" <[email-masked]> writes:

> nor should we support 8- or 16-bit systems.  If you'd prefer "uint32_t",
> I can do that.

Going into statinfo.h and updating sd_size to uint32_t is totally
outside the scope of this fix.

> I think using 2^31 is better because it's far away from very small
> values and very large values, which means that it's a hard to modify a
> file which used to have its value as a multiple of 4 GiB and
> accidentally make Git think it was unchanged.  Using 1 would make a
> simple "echo > foo" possibly think things were unchanged in some cases,
> which we should avoid.

The reason I gave the extreme "1-byte" was to gauge how much actual
"size" we are relying on the correctness of this change.  As mtime
is giving the primary protection from false matching of cached stat
information, I do not think "echo >foo" would be a huge issue.  IOW
my stance is 1U<<31 is as good as 1U<<0, so I do not oppose to the
former, either.  But in a few years, 64-bit integers may cease to be
too odd, who knows ;-)