docs(worktrees): triage a PR that won't merge, and how to resolve safely - #102
Merged
Conversation
…safely Four mergeStateStatus values read as "can't merge" and three need different fixes, which cost several sessions real time today. BLOCKED is the trap: right after a push every required check is pending and the PR reads BLOCKED, identical to genuinely failing. The fix is to count failures in statusCheckRollup before diagnosing -- zero failures plus pending checks means wait, not investigate. Also records that armed auto-merge does NOT update a BEHIND branch in this repo. Landing PR A puts PR B behind, and B then sits armed and stalled until somebody rebases it. That is not obvious from the UI, which shows auto-merge as enabled. The conflict-resolution half is the part with teeth. BACKLOG.md and CHANGELOG.md are single large append-target files, so they conflict most, and --ours/--theirs both yield a file that passes every check while silently dropping someone's work. No gate catches it because the result is well-formed. The worked example is real: two PRs each adding a "### Changed" block under [Unreleased], where the union was correct and either wholesale resolution would have dropped published entries. Closes with a find-and-replace warning found by the session that hit that conflict: re-verify a sweep AFTER resolving, not just after the original edit. Renumbering 252 to 316 across CHANGELOG.md turns cp1252 into cp1316, in a file nobody re-reads. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Written from what actually cost time today across several parallel sessions. Docs-only, one file, +45/−0.
Why
Four
mergeStateStatusvalues all read as "can't merge" and three need different fixes:BEHIND--force-with-lease— mechanicalDIRTYBLOCKEDUNKNOWNBLOCKEDis the trap. Right after a push every required check is pending and the PR readsBLOCKED— indistinguishable from genuinely failing. The rule added here is to count failures instatusCheckRollupfirst: zero failures + pending checks means wait, not investigate.Also records something not visible in the UI: armed auto-merge does not update a
BEHINDbranch in this repo. Landing PR A puts PR B behind, and B then sits armed and stalled until somebody rebases it, while the UI still shows auto-merge enabled. Observed repeatedly today — every stacked pair needed a manual rebase after the first landed.The half with teeth
docs/BACKLOG.mdandCHANGELOG.mdare single large append-target files, so they conflict most — and--ours/--theirsboth produce a file that passes every check while silently dropping someone's work. No gate catches it, because the result is well-formed.The worked example is real, from today: two PRs each added a
### Changedblock under[Unreleased]. The union was correct;--ourswould have dropped two already-published breaking-change notices,--theirswould have dropped the incoming one. Both would have merged green.Closes with a find-and-replace warning contributed by the session that hit that conflict: re-verify a sweep after resolving, not just after the original edit — conflict fixup is exactly when a sweep gets re-run carelessly. Renumbering
252→316acrossCHANGELOG.mdturnscp1252intocp1316, in a file nobody re-reads. Scope replacements to anchored forms (BACKLOG #252,## 252.), never the bare number.Verification
No code, no ledger number, no behaviour change. Does not touch
docs/BACKLOG.md— deliberately, since another session is mid-resolution in that file.🤖 Generated with Claude Code