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

"brian m. carlson" [off-list ref] writes:

quoted

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.