Hacker News Reader

Comment by ksherlock | Hacker News Reader

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)

View 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).

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.

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.

Reply on news.ycombinator.com