Thread

1. nicoburns · 1790875496 · 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 · 1790876629 · 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. metalliqaz · 1790880299 · focus · HN ↗

         changing repos to the new IDs would break any existing links to content on the pre-migration repos.

         1. AndrewDucker · 1790883713 · focus · HN ↗

            Unless you link using tags.

            1. crote · 1790889344 · focus · HN ↗

               Which is considered a Really Bad Idea because tags aren't immutable, so there's absolutely zero guarantee that it'll point to the same commit a few months from now.

               The GitHub Actions ecosystem found out the hard way, through some rather high-profile compromises. They hotfixed it by adding "immutable tags" to their platform, and are now working on adding a lockfile to... easily reference a commit hash.

               1. PunchyHamster · 1790898935 · focus · HN ↗

                  well if you use a knife to stab your fingers that's not a knife's fault

                  repo can also rewrite existing commit and you again won't be able to retrieve it so switching to commit IDs only lowers the level of failure somewhat

                  1. computerfriend · 1790916627 · focus · HN ↗

                     Having a fetch break is better than having a fetch pull down malware.

                     1. PunchyHamster · 1790986688 · focus · HN ↗

                        which I already said

                        > lowers the level of failure somewhat

                        congratulations on lack of ability to read with understanding

                        1. computerfriend · 1790995635 · focus · HN ↗

                           > congratulations on lack of ability to read with understanding

                           This seems weirdly aggressive and not nice.

Unofficial Hacker News client; not affiliated with Y Combinator.