Frode Nilssen’s Post

GitHub's merge queue silently rewrote main branch history on April 23rd. The pattern: PR shows a +29 / -34 diff. Reviewed, approved, queued. What lands is +245 / -1,137 — thousands of lines of already-shipped code quietly removed. Every merge after that stacks on the broken history. UI shows nothing wrong. GitHub says 2,800 PRs out of 4 million. One company reported 200+ on its own. Pick a number. The part nobody's saying out loud: for history to get overwritten like this, something is force-pushing to main behind the scenes. Branch protection apparently doesn't apply to GitHub itself. Worth thinking about what else moves through that path silently. The deeper issue isn't the bug. Bugs happen. The issue is that "distributed version control" became a single vendor's merge button for most of the industry, and the merge button lied for a day. Git itself was fine the whole time. It always is. I run my own Gitea. Recommend it. #GitHub #Git #DevOps #Gitea #SelfHosted #SoftwareEngineering

That’s the uncomfortable part, Frode, it’s not just the bug, it’s where the control actually sits. When something like this happens, you realise how much we’ve centralised workflows that were meant to be distributed. I’ve seen teams assume branch protection is absolute… until something bypasses it. Git being fine while the layer above it breaks says a lot. Do you think more teams will move back to self-hosted, or just add more safeguards on top?

To view or add a comment, sign in

Explore content categories