"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: >> +Documentation/technical/repository-version.txt) with the extension >> +`objectFormat`, and an optional core.compatMap configuration. >> >> [core] >> repositoryFormatVersion = 1 >> + compatMap = on >> [extensions] >> objectFormat = sha256 >> - compatObjectFormat = sha1 > > While I'm in favour of an approach that uses the compat map, the > situation we've implemented here doesn't specify the extra hash > algorithm. We want this approach to work just as well for moving from > SHA-1 to SHA-256 as it might for a future transition from SHA-256 to, > say, SHA-3-512, if that becomes necessary. > > Making a future transition easier has been a goal of my SHA-256 work > (because who wants to write several hundred patches in such a case?), so > my hope is we can keep that here as well by explicitly naming the > algorithm we're using. > > I also wonder if an approach that doesn't use an extension is going to > be helpful. Say, that I have a repository that is using Git 3.x, which > supports interop, but I also need to use Git 2.x, which does not. While > it's true that Git 2.x can read my SHA-256 repository, it won't write > the appropriate objects into the map, and thus it will be practically > very difficult to actually use Git 3.x to push data to a repository of a > different hash function. We might well prefer to have Git 2.x not work > with the repository at all rather than have incomplete data preventing > us from, well, interoperating. Very sensible line of thought and suggestion to move the topic forward. Very much appreciated.
