Filed from the LTX-2.5 landing campaign. This is a measurement, not a code change.
What happened
PR #880 reported mergeable: CONFLICTING on the forge. A local git merge of the same two commits is clean, including on .agents/issue-index.md, where both sides had appended a row.
Measured, both directions
Pre-merge head 42d34ca65, origin/main 4a4ab89cb, merge-base 0141cb4b4. Both sides genuinely touch the file:
pre-merge head changed .agents/issue-index.md? YES
main changed .agents/issue-index.md? YES
Local git resolves it with no conflict at either level:
git merge-tree --write-tree <main> 42d34ca65 -> rc=0, zero CONFLICT lines
git merge --no-commit --no-ff <main> -> rc=0
git status -- .agents/issue-index.md -> "M " (merged), not "UU"
merged file carries 204 rows
.gitattributes:7 declares .agents/issue-index.md merge=union, and union is a git built-in, so no per-clone merge.*.driver config is required. Locally the driver does exactly what #846 intended.
The forge disagreed anyway. The fix that unblocked #880 was a local merge of main into the branch (never a force-push); GitHub then recomputed against a tree where the append was already resolved.
Why this matters
#846 moved the issue index out of .agents/roadmap_v1.md and armed merge=union specifically so concurrent PRs would stop conflicting on bookkeeping — the problem tracked by #364 and #595. That worked locally, and the local result is what git merge and git merge-tree both report.
But if the forge still reports CONFLICTING, every author still sees a red mergeability badge on a union-merged path, and the natural response is to rebuild a branch that has nothing wrong with it. That is the cost #846 was trying to remove, and it is still being paid at the point where people actually look.
Operator consequence, worth stating plainly: a CONFLICTING verdict from the forge is not evidence of a conflict. Reproduce it with a local git merge before acting on it.
What is NOT established
I have not confirmed which path GitHub flagged, or the mechanism. The leading hypothesis is that GitHub computes mergeability without applying .gitattributes merge drivers. I did not verify that, and it should not be recorded as fact until someone does.
The experiment that settles it is cheap: branch twice off main, have each branch append one row to .agents/issue-index.md and change nothing else, push both, open a PR for the second, and read gh pr view --json mergeable. If that PR reports CONFLICTING, the hypothesis holds and the mechanism is confirmed on a case with exactly one variable. Close the throwaway PR and delete both branches afterwards.
Related: #364, #595, #846, #573.
FOLLOWING_AGENTS_PROTOCOL
Filed from the LTX-2.5 landing campaign. This is a measurement, not a code change.
What happened
PR #880 reported
mergeable: CONFLICTINGon the forge. A localgit mergeof the same two commits is clean, including on.agents/issue-index.md, where both sides had appended a row.Measured, both directions
Pre-merge head
42d34ca65,origin/main4a4ab89cb, merge-base0141cb4b4. Both sides genuinely touch the file:Local git resolves it with no conflict at either level:
.gitattributes:7declares.agents/issue-index.md merge=union, andunionis a git built-in, so no per-clonemerge.*.driverconfig is required. Locally the driver does exactly what #846 intended.The forge disagreed anyway. The fix that unblocked #880 was a local merge of
maininto the branch (never a force-push); GitHub then recomputed against a tree where the append was already resolved.Why this matters
#846 moved the issue index out of
.agents/roadmap_v1.mdand armedmerge=unionspecifically so concurrent PRs would stop conflicting on bookkeeping — the problem tracked by #364 and #595. That worked locally, and the local result is whatgit mergeandgit merge-treeboth report.But if the forge still reports
CONFLICTING, every author still sees a red mergeability badge on a union-merged path, and the natural response is to rebuild a branch that has nothing wrong with it. That is the cost #846 was trying to remove, and it is still being paid at the point where people actually look.Operator consequence, worth stating plainly: a
CONFLICTINGverdict from the forge is not evidence of a conflict. Reproduce it with a localgit mergebefore acting on it.What is NOT established
I have not confirmed which path GitHub flagged, or the mechanism. The leading hypothesis is that GitHub computes mergeability without applying
.gitattributesmerge drivers. I did not verify that, and it should not be recorded as fact until someone does.The experiment that settles it is cheap: branch twice off
main, have each branch append one row to.agents/issue-index.mdand change nothing else, push both, open a PR for the second, and readgh pr view --json mergeable. If that PR reportsCONFLICTING, the hypothesis holds and the mechanism is confirmed on a case with exactly one variable. Close the throwaway PR and delete both branches afterwards.Related: #364, #595, #846, #573.
FOLLOWING_AGENTS_PROTOCOL