Whatever happened to SHA-256 support in Git?

Posted Jun 23, 2022 19:48 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Parent article: Whatever happened to SHA-256 support in Git?

The last time SHA-256 in git came up, I almost vomited from the clumsy format for hashes that they'd chosen. Hashes in SHA-1 are in binhex, why not instead just use a different alphabet to encode SHA-256 hashes?

And it's not hard to do. For example, instead of 0-9a-f use g-v. Or abuse the first letter of the hash as the version.

Whatever happened to SHA-256 support in Git?

Posted Jun 24, 2022 17:54 UTC (Fri) by khim (subscriber, #9252) [Link]

You can even do both at the same time: “h” would mean “normal SHA256-bit hash in 65 letters” and “stuvwxyz” would start “40-letters long SHA256-bit hash” (if you take ASCII, excluse 37 “really bad” symbols, e.g. first 32, 127, “ ”, “%”, “$” and “.” then you can encode 13 bits in two characters).

This way you would even have an option for these old tools where 40-letters space is reserved for hash.

This should not be a default because at some point even longer hash would be needed, most likely.

Whatever happened to SHA-256 support in Git?

Posted Jun 30, 2022 10:35 UTC (Thu) by Karellen (subscriber, #67644) [Link]

My first thought was to prefix hashes with the hash type and a separator, e.g. "sha256:0123...". That way you could add new hashes whenever the devs wanted, by just adding the algorithm and assigning a new prefix. Any hash already stored inside a git repo that is not preceded by a type is automatically assumed to be sha1. A commit with an sha256 hash could have parents with either sha256 or sha1 hashes, or even both!

The way they decided to go about things (last I checked) did seem a bit constraining.