On 2023-09-08 at 23:10:19, Eric W. Biederman wrote: > Ir makes a lot of sense for the hash algorithm that determines how all Minor nit: "It". > diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt > index 4b937480848a..10572c5794f9 100644 > --- a/Documentation/technical/hash-function-transition.txt > +++ b/Documentation/technical/hash-function-transition.txt > @@ -148,14 +148,14 @@ Detailed Design > Repository format extension > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > A SHA-256 repository uses repository format version `1` (see > -Documentation/technical/repository-version.txt) with extensions > -`objectFormat` and `compatObjectFormat`: > +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. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
