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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2023, 22:11 UTC
Message-ID: <xmqqzg0n32zo.fsf@gitster.g>
In-Reply-To: <ZShsG1SKfrefsCtu@tapette.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> 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.

Show 6 quoted lines

> 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 ;-)