On 8/22/2019 10:17 PM, brian m. carlson wrote: > 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. Absolutely, it is not. It would be a great place to store a transition table, when that is needed. If we _never_ allow both hashes in the .git folder, then maybe we won't ever need this and can rely on config options. I imagine that will be tricky, and updating this byte should only help. We are not ready for that, anyway. Thanks, -Stolee
