3 ms·

>>> This made me think... why are we using long, unwieldy base-16 hex strings at all? Surprised you got ten answers to this comment and nobody was able to expl

>>> This made me think... why are we using long, unwieldy base-16 hex strings at all? Surprised you got ten answers to this comment and nobody was able to explain. Hexadecimal encoding is widely used because computers work with bytes (8 bits). An hexadecimal character is 4 bits, so every byte is two hex characters. It's trivial to encode (even by hand), it has no issue of padding. It can truly transit through anything that accepts alphanumeric characters. It's awesome. edit: The most common alternative is base64 that encodes blocks of 3 bytes to 4 characters. Base64 has a bazillion issues due to padding and special characters +/=. If I had a dollar for every system I've seen using broken base64, I could buy a car. Saving a bit of space (200% in hex VS 134% size in base64) is almost never worth an order of magnitude more complexity. Do not invent your own encoding algorithm.

ptx 6y ago
In this specific context though, nobody is going to be manually calculating the binary hash of the source tree and encoding it, so this advantage doesn't seem very relevant. The proposed solution would still be alphanumeric, so it would share that advantage.
- deleted 6y ago
  [deleted]
- notriddle 6y ago
  The problem isn't with the algorithm encoding it. The problem is with other software mangling it. Base 64 has punctuation, it's case sensitive, and trimming a = off the end will (counterintuitively) result in a longer payload. All of this makes screwing around with commit hashes more complicated.
mkl 6y ago
I think you've kind of missed the point, which is that a larger base would mean shorter hash strings. Using a small base like 16 means the hashes are very long, and awkward to use in full. Using a larger base will make the hash shorter when it's in text form. A text representation of a 256 bit hash in base 16 is 64 characters long, but in base 46 it is only 47 characters long. Using the whole alphabet in lower and upper case, and the digits, would produce base 62, where a 256 bit hash would be 43 digits long. Still a bit big and unwieldy IMHO, so sticking with hexadecimal seems sensible given its other advantages.
kelnos 6y ago
> Hexadecimal encoding is widely used because computers work with bytes (8 bits). An hexadecimal character is 4 bits, so every byte is two hex characters. Yes, I'm aware (that electrical & computer engineering degree I have is occasionally good for something ;) ). But the dominating factor in hashing a bunch of data is the hash function itself, not converting it into something displayable. Converting between binary and hex vs. binary and some other base string is optimizing the wrong part of the process. And who is converting SHA1 hashes between hex and binary by hand? That doesn't seem like a thing people do.

ptx 6y ago

In this specific context though, nobody is going to be manually calculating the binary hash of the source tree and encoding it, so this advantage doesn't seem very relevant. The proposed solution would still be alphanumeric, so it would share that advantage.

deleted 6y ago
[deleted]
notriddle 6y ago
The problem isn't with the algorithm encoding it. The problem is with other software mangling it. Base 64 has punctuation, it's case sensitive, and trimming a = off the end will (counterintuitively) result in a longer payload. All of this makes screwing around with commit hashes more complicated.

mkl 6y ago

I think you've kind of missed the point, which is that a larger base would mean shorter hash strings. Using a small base like 16 means the hashes are very long, and awkward to use in full. Using a larger base will make the hash shorter when it's in text form. A text representation of a 256 bit hash in base 16 is 64 characters long, but in base 46 it is only 47 characters long. Using the whole alphabet in lower and upper case, and the digits, would produce base 62, where a 256 bit hash would be 43 digits long. Still a bit big and unwieldy IMHO, so sticking with hexadecimal seems sensible given its other advantages.

kelnos 6y ago

> Hexadecimal encoding is widely used because computers work with bytes (8 bits). An hexadecimal character is 4 bits, so every byte is two hex characters. Yes, I'm aware (that electrical & computer engineering degree I have is occasionally good for something ;) ). But the dominating factor in hashing a bunch of data is the hash function itself, not converting it into something displayable. Converting between binary and hex vs. binary and some other base string is optimizing the wrong part of the process. And who is converting SHA1 hashes between hex and binary by hand? That doesn't seem like a thing people do.