5 ms·

96a2dff2ba1aceed1994fddd9adc276556c789c52d3e5f8a1721703a461d41ab4ddd9563075e8adda6382a8c9d52be78ae07eec77dcfba58978ea87290a9028f SO BIG. For git, most people

by base698 10y ago

96a2dff2ba1aceed1994fddd9adc276556c789c52d3e5f8a1721703a461d41ab4ddd9563075e8adda6382a8c9d52be78ae07eec77dcfba58978ea87290a9028f SO BIG. For git, most people don't realize in most cases if the repo isn't giant you can use just 96a as a shortcut. I imagine people would be turned off by the sheer size.

OJFord 10y ago
The CLI could always just truncate it to 256b (or fewer) when used interactively.
Buttons840 10y ago
96a is not the full hash in git currently. Why couldn't you also refer to the above hash as 96a as well?
- base698 10y ago
  You could, I was just saying I run across a lot of people that don't know you can reference them that way.
deleted 10y ago
[deleted]
npongratz 10y ago
If I were eyeballing two hashes to make sure they were equal, I'd worry about my ability to see near collisions (similar to [0]) the longer the hashes were. My eyes just start skipping ahead at some point, and would probably miss different-but-similar-looking characters in the middle. But I think SHA-512 is resistant to near-collisions (sorry, I don't have a citation), and besides, one would probably best compare hashes using a script one understands. [0] http://link.springer.com/content/pdf/10.1007%2F978-3-540-28628-8_18.pdf http://link.springer.com/content/pdf/10.1007%2F978-3-540-286...
- jgrowl 10y ago
  Maybe we just need better tooling to help us compare hashes easier. Not exactly sure what that would look like though.
  - throwawayish 10y ago
    Color the character boxes and display in two adjacent lines.
- syrrim 10y ago
  >I think SHA-512 is resistant to near-collisions All good hash functions have an even distribution, and are therefore resistant to near-collisions. Hash tables for example require this property to work properly.
wtbob 10y ago
KFyFwOkYdQatN3ZVjB16K3aY4KoydUr54rgfux33PuliXjqhykKkCjw is quite a bit nicer, I think, albeit case-sensitive. s2rn74v2dlho2gmu7xozvxbhmvlmpcoffu7f7cqxefydurq5igvu3xmvmmdv5cw5uy4cvde5kk7hrlqh53dx3t52lcly5kdsscuqfdy is at least not case-sensitive.

by base698 10y ago

OJFord 10y ago

The CLI could always just truncate it to 256b (or fewer) when used interactively.

Buttons840 10y ago

96a is not the full hash in git currently. Why couldn't you also refer to the above hash as 96a as well?

base698 10y ago
You could, I was just saying I run across a lot of people that don't know you can reference them that way.

deleted 10y ago

[deleted]

npongratz 10y ago

If I were eyeballing two hashes to make sure they were equal, I'd worry about my ability to see near collisions (similar to [0]) the longer the hashes were. My eyes just start skipping ahead at some point, and would probably miss different-but-similar-looking characters in the middle. But I think SHA-512 is resistant to near-collisions (sorry, I don't have a citation), and besides, one would probably best compare hashes using a script one understands. [0] http://link.springer.com/content/pdf/10.1007%2F978-3-540-28628-8_18.pdf http://link.springer.com/content/pdf/10.1007%2F978-3-540-286...

jgrowl 10y ago
Maybe we just need better tooling to help us compare hashes easier. Not exactly sure what that would look like though.
- throwawayish 10y ago
  Color the character boxes and display in two adjacent lines.
syrrim 10y ago
>I think SHA-512 is resistant to near-collisions All good hash functions have an even distribution, and are therefore resistant to near-collisions. Hash tables for example require this property to work properly.

wtbob 10y ago

KFyFwOkYdQatN3ZVjB16K3aY4KoydUr54rgfux33PuliXjqhykKkCjw is quite a bit nicer, I think, albeit case-sensitive. s2rn74v2dlho2gmu7xozvxbhmvlmpcoffu7f7cqxefydurq5igvu3xmvmmdv5cw5uy4cvde5kk7hrlqh53dx3t52lcly5kdsscuqfdy is at least not case-sensitive.