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