On 2019-08-22 at 14:04:16, Derrick Stolee wrote: > On 8/18/2019 4:04 PM, brian m. carlson wrote: > > diff --git a/midx.c b/midx.c > > index d649644420..f29afc0d2d 100644 > > --- a/midx.c > > +++ b/midx.c > > @@ -19,8 +19,7 @@ > > #define MIDX_BYTE_NUM_PACKS 8 > > #define MIDX_HASH_VERSION 1 > > This hash version "1" is the same as we used in the commit-graph. It's > a byte value from the file format, and we've already discussed how it > would have been better to use the 4-byte identifier, but that ship has > sailed. I'm just pointing this out to say that we are not done in this > file yet, but we can get to that when we want to test the midx with > multiple hash lengths. My approach so far has been to assume everything in the .git directory is in the same hash except for the translation functionality. Therefore, it doesn't make sense to distinguish between hashes in the midx files, because we'll never have files that differ in hash. So essentially the MIDX_HASH_VERSION being 1 is "whatever hash is being used in the .git directory", not just SHA-1. In addition, the current multi-pack index format isn't capable (from my reading of the documentation, at least) of handling multiple hash algorithms at once. So we'd need a midx v2 format for folks who are using SHA-256 with SHA-1 compatibility and we could then write separate sets of object chunks with an appropriate format identifier, much like the proposed pack index v3. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
