Subject: Re: [PATCH 0/4] hash.h: support choosing a separate SHA-1 for non-cryptographic uses

From: Junio C Hamano <[email-masked]>
Date: Thu, 05 Sep 2024 14:27:47 -0700

Jeff King <[email-masked]> writes:

> But I'm not sure how comfortable I am leaving us in that state, even if
> it is by itself OK. It feels fragile, and we're a small step away from
> somebody accidentally using the "fast" variant to do reading.

Yup, avoiding to rename over an existing files makes the gives us a
lot more defensive posture.

>   Side note: I do really like the xxHash direction in general, but I
>   think we may be underestimating the difficulty. Obviously it needs a
>   protocol extension for sending packfiles, but what about other
>   cross-repo access? E.g., dumb http blindly downloads the packfiles.
>   How does it learn which hash is in use?

We need to make the file contents a bit more self describing
regardless.  A dumb http clone should look more or less like

 - download "packfiles"
 - download "info/refs"

 - run verify-pack on the packfiles
 - create an empty repository
 - move the pack we downloaded to .git/objects/pack/
 - populate refs from downloaded info/refs

 - make sure the tips of refs are all connected.

but as we recently discussed how verify-pack and index-pack assumes
the hash algorithm in the receiving repository, we need to give a
bit more clue in packfiles themselves what hash algorithms they use,
etc.