3 ms·

Has anyone considered doing "add16" on the first character of the sha-256 hash, e.g., so the SHA-256 hash 1d06... becomes hd06... ? Then you could see, from the

Has anyone considered doing "add16" on the first character of the sha-256 hash, e.g., so the SHA-256 hash 1d06... becomes hd06... ? Then you could see, from the first character, if it is SHA-1 or SHA-256. Having a clear distinction on the first character would make it clear which hash is being used (without needing lots of chars).

avar 4y ago
I think this was discussed at some point early on, there's many outstanding issues with Git's SHA-1<->SHA-256 interop and potential unknowns, but figuring out which format a given abbreviated hash is in isn't really one of them. For any internal part of Git the hash type is already known, e.g for the wire protocol dialog that "fetch" runs. Other commentators have pointed out that you can use the hash length to disambiguate the two, but the way it's implemented internally we could tell them apart even if we hypothetically had two hashes of the same length. But that leaves abbreviated hashes, e.g. if you do "git show deadbeef" is that a SHA-1 or SHA-256 hash? We don't know. It's forseen that in those cases we'll look up both, and in the case of ambiguity do the same thing as e.g. "git show dead" does now (try it on a non-trivially sized repo). Then just as you can do e.g. "git show dead^{commit}" now to disambiguate, you'd use the ^{sha1} or ^{sha256} peel syntax (still unimplemented). If we changed the hash format from [0-9a-f]{4,40} to something that didn't match the first part of that regex there's even more downstream systems that would need adjusting. A lot of programs that work with Git's output use some variant of that regex. For those that don't limit themselves to "40" things usually Just Work. So that's basically the reason, it's also less future-proof, as you'll run out of magical prefix characters faster than you'll run out of hash names. Although I'm hoping to be dead way before that small space would be exhausted :)

avar 4y ago

I think this was discussed at some point early on, there's many outstanding issues with Git's SHA-1<->SHA-256 interop and potential unknowns, but figuring out which format a given abbreviated hash is in isn't really one of them. For any internal part of Git the hash type is already known, e.g for the wire protocol dialog that "fetch" runs. Other commentators have pointed out that you can use the hash length to disambiguate the two, but the way it's implemented internally we could tell them apart even if we hypothetically had two hashes of the same length. But that leaves abbreviated hashes, e.g. if you do "git show deadbeef" is that a SHA-1 or SHA-256 hash? We don't know. It's forseen that in those cases we'll look up both, and in the case of ambiguity do the same thing as e.g. "git show dead" does now (try it on a non-trivially sized repo). Then just as you can do e.g. "git show dead^{commit}" now to disambiguate, you'd use the ^{sha1} or ^{sha256} peel syntax (still unimplemented). If we changed the hash format from [0-9a-f]{4,40} to something that didn't match the first part of that regex there's even more downstream systems that would need adjusting. A lot of programs that work with Git's output use some variant of that regex. For those that don't limit themselves to "40" things usually Just Work. So that's basically the reason, it's also less future-proof, as you'll run out of magical prefix characters faster than you'll run out of hash names. Although I'm hoping to be dead way before that small space would be exhausted :)