On Wed, Dec 19, 2018 at 09:52:12PM -0500, Jeff King wrote: > On Thu, Dec 20, 2018 at 12:17:53AM +0000, brian m. carlson wrote: > > > On Wed, Dec 19, 2018 at 10:27:35AM -0500, Jeff King wrote: > > > I dunno. This is one of those dark corners of the code where we appear > > > to do the wrong thing, but nobody seems to have noticed or cared much, > > > and changing it runs the risk of breaking some obscure cases. I'm not > > > sure if we should bite the bullet and try to address that, or just back > > > away slowly and pretend we never looked at it. ;) > > > > I will point out that with the SHA-256 work, reading the config file > > becomes essential for SHA-256 repositories, because we need to know the > > object format. Removing the config file leads to things blowing up in a > > bad way (what specific bad way I don't remember). > > > > That may influence the direction we want to take in this work, or not. > > Wouldn't we just treat that the same way we do now? I.e., assume the > default of sha1, just like we assume repositoryformatversion==0? Yeah, we'll default to SHA-1, but the repository will be broken. HEAD can't be read. Trying to run git status dies with "fatal: Unknown index entry format". And so on. We've written data with 64-character object IDs, which can't be read by Git in SHA-1 mode. My point is essentially that in an SHA-256 repository, the config file isn't optional anymore. We probably need to consider that and error out in more situations (e.g. unreadable file or I/O error) instead of silently falling back to the defaults, since failing loudly in a visible way is better than having the user try to figure out why the index is suddenly "corrupt". -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
