On Tue, Feb 12, 2019 at 12:08:01PM +0100, Ævar Arnfjörð Bjarmason wrote: > Both this & the follow-up 29/31 look scary since this is an on-disk > structure and this patch & the next one rather than implementing some > transition, just changes the structs & code we use to read & write to > use the current hash size. > > So what are we going to do when the "current" size is SHA-256 and our > on-disk cache is SHA-1? It seems like with this we'd at best (I haven't > tested) throw away the SHA-1 UC data, and at worst introduce some silent > persistent read failure. That's a good question. The current design has everything in the .git directory other than the loose object table and the pack indices in one algorithm. That is, the untracked cache extension, like the rest of the index, will always be SHA-256 when the objects are stored in SHA-256. Having mixed algorithms in the .git directory would add a lot of complexity. > In any case that seems like something we should have tests for with an > on-disk format, i.e. write in one hash, see what happens when we read in > another, and perhaps instead of not understanding SHA-1 hashes in > SHA-256 mode we'd read the SHA-1 and consult the SHA-1<->SHA-256 lookup > table we're going to be eventually maintaining on the side? Correct. The current plan is that when the transition code is fully implemented, we'll read object IDs from the user in whatever algorithms we support, translate them into the default algorithm, and then use them. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
