Re: [PATCH 1/9] docs: update pack index v3 format

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 20, 2025, 17:01 UTC
Message-ID: <xmqqseghxdlm.fsf@gitster.g>
In-Reply-To: <aM7G22LJ47nx8Wqk@fruit.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 17 quoted lines

>> I do also agree that 32-byte is the natural size for the trailing
>> hash, but I found that the two paragraphs below was far more than
>> necessary.  As they argue, we use a truncated hash anywhere in our
>> file formats, so I would have understood if the explanation were
>> 
>>     "20" in "A copy of the 20-byte SHA-256 checksum" is an obvious
>>     typo, as SHA-256 is longer than that.  Fix it to "32".
>> 
>> instead of these two paragraphs.
>> 
>> Or did we mean to use a truncated hash back when this transition
>> design was proposed originally?
>
> I think we intended to use a 20-byte value originally because we felt we
> didn't need the full 32 bytes for an index or pack checksum.  However,
> as I mentioned, we use the 32-byte checksum for SHA-256 already, so all
> it does is add complexity to try to mandate a 20-byte value.

I think we are saying the same thing but from different sides of the same mirror.

SHA-256 packs and any csum-file based file would be using 32-byte checksum because with CSUM_HASH_IN_STREAM, finalize_hashfile() does not know any way to produce the trailing hash other than writing the full hash value, and that would be 32 bytes for SHA-256. This was exactly where my "20 certainly is a typo" impression came from.

Be it a typo or misdesign, picking 32 instead of 20 is a good thing to do now for a subsystem and fileformat that is not used anywhere in producation yet.

Thanks.