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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2024, 21:27 UTC
Message-ID: <xmqqbk11zt7w.fsf@gitster.g>
In-Reply-To: <20240905202707.GA2602440@coredump.intra.peff.net>

Jeff King <peff@peff.net> 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.

Show 5 quoted lines

>   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.