Re:Linus on Git and SHA-1
by ksherlock on Saturday February 25, 2017 @04:14PM
(#13733855)
On the mailing list he suggested displaying 160 bits for backwards compatibility with existing tools. The full 256 bits would be used internally (and displayed externally with the proper --flag)
[ Parent
| on HN ]
additionally cosmetics but instead of hex string could they not use a-zA-Z0-9 in the visual output to the user to make the git command line text output shorter?
0efaa. -> 2AdC..
Unfortunately there's a lot of code out there that assumes commit hashes are case-insensitive and hexadecimal... I've written some myself. It'd be a hugely painful change.
Then you have stuff like 1, I and l, which are difficult to distinguish. Which was why base58 was invented (basically the range you suggested, without visually similar characters).
And zbase32 (https://philzimmermann.com/docs/human-oriented-base-32-encod...), which is my own preference for still being case-insensitive and thereby able to be used in subdomain names or email addresses.
This really should not be a problem since that's task #1 that a programmer's good font needs to solve.
I often run into git hashes places where a programming font wouldn't apply, like URLs and web pages.
>where a programming font wouldn't apply, like URLs
Any phisher's wet dream is a URL displayed in a font where l and I look the same. For anything that routinely displays URLs, font matters a lot. And any website displaying git hashes is likely to be programming related and have some code-font (good monospace or similar) in it's repertoir.