From: Junio C Hamano Date: Sat, 20 Sep 2025 17:01:25 GMT Subject: Re: [PATCH 1/9] docs: update pack index v3 format Message-ID: In-Reply-To: "brian m. carlson" writes: >> 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.