‹ BackHN Continuity

Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

  1. nicoburns · · focus · HN ↗
    From what I'd read, SHA256 in git is showing every sign of being another IPv6. In particular:

    - It's implemented in a non-backwards-compatible way

    - The benefits over the older model are a bit nebulous

    - There's a large amount of tooling that needs to catch up, and little sign that there is movement there

    1. sltkr · · focus · HN ↗
      The difference with IPv6 adoption is that the internet relies heavily on network effects: so long as some hosts only have an IPv4 address, you need an IPv4 address for full connectivity, but then if everyone has an IPv4 address anyway, there is no immediate need to migrate to IPv6.

      (Yes us Hacker News users have plenty of use cases for IPv6, like self-hosting and peer-to-peer networking and so on; we are not the average user.)

      This effect doesn't exist for the Git migration. Each repo can be updated independently; it doesn't affect users of other repositories, and most likely, the majority of devs will work on some SHA-1 repos and some SHA-256 repos with no issue.

      If anything, I would compare it with the Python 2 to Python 3 migration, which was also painful, but succeeded eventually (despite being much less necessary in the first place).

      1. kllrnohj · · focus · HN ↗
        > Yes us Hacker News users have plenty of use cases for IPv6, like self-hosting

        Funnily enough, self hosting is why I can't use IPv6. I want vlan isolation, but only get a /64 from my ISP.

        Fortunately the lack of IPv6 also isn't a meaningful loss anyway so whatever

        1. Dylan16807 · · focus · HN ↗
          What kind of isolation are you looking for? Vlans might still be possible.
        2. someonebaggy · · focus · HN ↗
          FWIW there's nothing about the addresses themselves that stops you subdividing a /64, but it depends on your router.

          You could put your server at x::1 and static-route that address as a /128 on your router, if it supports it. The reverse route might be a bit tricky but putting ::0 on the router and telling the server it's a /127 should work. Anything outside of the /127 (so, all the randomly generated addresses on your home network) would go back through the router.

          Now if that /64 is also changing every day, then it's a problem and idk what you'd do.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.