The Skill Issue Institute is pleased to recognize Prof. Rebase Schrodinger (Class of 2023) for a distinguished contribution to merge queue philosophy: demonstrating that a pull request can be both merged and not meaningfully present on the default branch.
On April 23, 2026, between 16:05 and 20:43 UTC, Prof. Schrodinger’s work appeared in a regression affecting GitHub’s Pull Requests service. The issue involved a precise and academically satisfying combination of features: merge queue, squash merge, and merge groups containing more than one pull request. When those conditions aligned, the resulting merge commits could be incorrect, with later merges inadvertently reverting changes from earlier pull requests.
The root cause was an unreleased code path that adjusted merge base computation for merge queue ref updates. It was intended to remain behind a feature flag, but the gating was incomplete. Our Governance of Booleans department considers this a landmark example of feature flag architecture: the switch existed, the feature existed, and production was invited to mediate their disagreement.
GitHub later reported that 658 repositories and 2,092 pull requests were affected. There was no data loss, because the commits still existed in Git, but affected default branches could end up in the wrong state. This subtle distinction has already been accepted as required reading in GIT 202: Merge Conflicts as Modern Art. Losing code is unfortunate; retaining all the code while placing the branch in the incorrect timeline is scholarship.
“The important thing is that every commit was still somewhere,” Prof. Schrodinger explained during our Correctness Versus Availability symposium. “Students often over-focus on whether the main branch contains the intended result. I encourage them to ask the richer question: intended by whom?”
Existing monitoring did not detect the incident because the service remained available and the merges completed. The defect concerned merge correctness rather than uptime, and was identified after customer support inquiries increased. Our Site Reliability faculty describes this as a mature observability posture: all systems operational, except for the part where the system did the wrong thing successfully.
Recovery required GitHub to revert the code change, force-deploy the fix, identify affected repositories, and send targeted remediation guidance to repository administrators. Some teams had to manually inspect history, restore reverted changes, and re-merge or force-push their way back to the branch they thought they already had.
Prof. Schrodinger’s achievement now anchors a new practicum in the Master’s in Git Conflict Resolution: if your tests only cover one pull request at a time, the second pull request is free to pursue independent research.
Original source: GitHub bug messed up customer code; COO plays down incident