Github are you joking?

Summary

The video argues that a serious GitHub malfunction effectively broke core expectations about Git history during merge-queue operations, causing silent and large-scale reversion or loss of previously merged changes on customer main branches.

What allegedly happened

• GitHub introduced a regression in merge queue behavior (reported around April 23), where some merges (e.g., squash/rebase) were produced from an incorrect base state.
• According to reports discussed in the video, GitHub’s merge queue would sometimes overwrite history rather than apply changes correctly:
  • A PR could appear normal in the UI (diff looked fine, PR reviewed/approved/queued).
  • But what actually landed on main was a drastically different result—described as removing thousands of lines of unrelated, already-shipped code.
• The video emphasizes that the issue reportedly involved Git-level history changes (described as “reverting” in effect, not necessarily a visible small code diff).
• It also claims that subsequent merges built on the broken state, compounding the problem.

Impact and scale uncertainty

• Companies/teams reportedly spent hours to days detangling missing or reverted commits across PRs and branches.
• GitHub’s reported numbers are disputed in the commentary:
  • One figure mentioned: 2,804 PRs affected.
  • Later figures contradicted this (the video cites an alternative magnitude, making the difference between ~0.07% and a much larger ~0.3%+, depending on which number is correct).
• The creator notes there is no official GitHub postmortem provided in the discussion, so the exact scope and root cause remain unclear.

Root cause speculation and “how could Git allow this?”

• The video claims (based on reports, not an official explanation) that merge queue internal logic created an intermediate squashed merge state and then applied it to main in a way that overwrote the expected history.
• Technical concerns raised by the presenter include:
  • Would this normally cause obvious Git issues like divergent history (making pulls fail)?
  • Would the only way be force-pushing or other history-altering mechanisms internally?
  • If so, the presenter worries about what other hidden risks might exist.
• Other explanations mentioned as circulating elsewhere include:
  • A faulty feature flag
  • General speculation about whether automation (even AI-themed humor) played a role—though the video stresses it “wasn’t AI” in at least one framing.

Broader commentary

• The video portrays the incident as especially damaging because GitHub is expected to preserve Git’s integrity; silent history manipulation undermines trust.
• It also suggests the incident will become a convenient excuse for future mishaps (“not our fault, GitHub did it”).
• The video highlights frustration and confusion visible in public discussions, including on Hacker News.

Note: The claims summarized above are presented as the video’s interpretation of reports and community commentary; an official postmortem is not referenced in the discussion.

Presenters / Contributors

• No specific named contributors are identified in the subtitles.
• The presenter/narrator is the sole voice speaking throughout.
• External sources referenced (not presenters): “large companies” reporting the issue, Hacker News, and “Claude Opus” (mentioned as a playful reference).