3 ms·
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
by ksherlock 10y ago
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)
- diminish 10y agoadditionally 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..
- pshc 10y agoUnfortunately 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.
- runeks 10y agoThen 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).
- kzrdude 10y agoThis really should not be a problem since that's task #1 that a programmer's good font needs to solve.
- cbr 10y agoI often run into git hashes places where a programming font wouldn't apply, like URLs and web pages.
- wongarsu 10y ago>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.
- derefr 10y agoAnd zbase32 (https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt 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.