Thread

1. MBCook · 1790876427 · focus · HN ↗

   So they’ve been talking about this for many years, planning, and finally announce when they’re going to switch the default.

   So this is the right time to post that everything they’re doing is wrong? Did you engage in all the discussions about it and how best to handle it? Whether SHA-256 was the best solution?

   I don’t see anywhere that it talks about alternate proposals or why they might have been better. Why the particular suggestions here were rejected.

   This seems like a bunch of Monday morning quarterbacking.

   1. schacon · 1790876621 · focus · HN ↗

      I do mention this in like the first paragraph. I don't feel great about it, but I've listened to these issues for years now during contributor summits and Git Merge talks and while it's always seemed problematic, I thought they would come up with a good solution. This last Git Merge confirmed that it's close to the switch and not in any way solved or improved. I don't want to just go with it for groupthink reasons. I never thought it was a good idea and I have said that, but we have a last chance to rethink this, so I'm curious if I'm alone or in the silent majority.

      1. throwworhtthrow · 1790877356 · focus · HN ↗

         Your argument is persuasive and well illustrated. I think the problem is the intro paragraphs come off as too certain of catastrophe which, when juxtaposed with your claim that "smarter people than me have been working on this", makes it sound like you don't actually believe they're smarter than you. The rest of your essay feels fair and not judgmental.

         1. schacon · 1790878867 · focus · HN ↗

            I do believe they're smarter than me, but sometimes very smart groups talk themselves into ultimately impractical solutions because they're all smart. Sometimes you need a dumb guy to come in and say "are you sure this is right?"

            1. throwworhtthrow · 1790879372 · focus · HN ↗

               I believe you are sincere. But "is about to be a huge, costly, global train wreck" lacks the nuance of "are you sure this is right?" and will rub some people the wrong way.

               Edit: I'm not suggesting you should have written it any differently. I think you made the right choice to be a bit provocative because it grabs the attention that's needed.

               1. schacon · 1790880073 · focus · HN ↗

                  I do believe this. But that doesn't mean I can't be convinced otherwise by a good argument. The point of this post is to see if anyone has a great counterargument to change my mind.

                  1. conartist6 · 1790950535 · focus · HN ↗

                     I think you're basically right about this: if you're going to ask an ecosystem to bear the costs of a breaking change, you should be asking yourself what will be bought for the price you will pay.

                     For users it's a set of scales that hangs in balance. On one side is the disruptiveness of the change to them, and on the other is the promise of what they will gain once on the other side.

                     If there's a problem with the current thinking it's that it proposes to trigger a big expensive breakage that we'll be paying for for 10 years, but there hasn't been any serious discussion of what else is broken about git that needs to be fixed to git to continue to be relevant for the next 10 years.

                     Most discussions are pre-constrained by the idea that ecosystem wide breakages are impossible.

                     In theory it's good for me if the git ecosystem splits compatibility in half with no obvious benefit. That just makes it easier for me to waltz in with a third backwards-incompatible migration path, one which actually offers eye-popping kinds of benefits in return for the cost of the breakage. That's why I'm competing with you in the race to replace Github. It's just that I'm also racing to replace git, so I assume you'll be in some amount of trouble if I should succeed.

Unofficial Hacker News client; not affiliated with Y Combinator.