#1108 gave CHANGELOG.md a union merge driver and closed #996. Its body left one question open and said so plainly:
GitHub's server-side merge is not guaranteed to honour a .gitattributes merge driver, so this removes the conflict for local merges and rebases — which is where the nine-a-day cost is paid — and may or may not change what the merge button does. I have not tested the button, and say so rather than claim it.
It is tested now. GitHub does not honour it.
Measured
#1113 went CONFLICTING on GitHub the moment #1109 merged. The same merge, run locally with the driver in place:
$ git merge origin/main # into #1113's head
Auto-merging CHANGELOG.md
Merge made by the 'ort' strategy.
rc=0
conflicted files: (none)
And the union result is correct, not merely quiet:
## [Unreleased] headings : 1
### Fixed under it : 1
duplicate bullet lines : 0
conflict markers : 0
docs_style.sh : 42 checks, PASSED
with every entry present — #996, #1030, #965's two, #1032, #1090 — in one section.
So the driver works exactly as #1108 argued. GitHub's mergeability calculation and its merge button do not read .gitattributes, so the red "This branch has conflicts" badge appears anyway.
What this changes
Nothing about whether #1108 was right. The nine-a-day cost was local merges and rebases, and that cost is gone: four branches have rebased onto the driver with zero CHANGELOG conflicts since it landed.
What it changes is the instruction. A contributor who sees CONFLICTING on their PR must rebase locally and push. Clicking "Update branch" on GitHub, or waiting for the button, gets them the conflict the driver exists to remove. That is worth writing down, because the failure is confusing in the specific way that costs time: the tree merges cleanly on their machine and the web UI says it does not.
Options
- Document it and move on. Cheapest, and matches what the driver actually buys.
- Have CI or a bot rebase, so the button is never the path.
- Nothing — accept the badge as noise.
I would take 1. The badge is wrong rather than harmful, and the measurement above is the thing a confused contributor needs.
Filed rather than left in a thread because #1108's body asked the question explicitly and the answer belongs where someone will find it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NhwXKAgSmYDUjteWkfajHK
#1108 gave
CHANGELOG.mda union merge driver and closed #996. Its body left one question open and said so plainly:It is tested now. GitHub does not honour it.
Measured
#1113wentCONFLICTINGon GitHub the moment#1109merged. The same merge, run locally with the driver in place:And the union result is correct, not merely quiet:
with every entry present — #996, #1030, #965's two, #1032, #1090 — in one section.
So the driver works exactly as #1108 argued. GitHub's mergeability calculation and its merge button do not read
.gitattributes, so the red "This branch has conflicts" badge appears anyway.What this changes
Nothing about whether #1108 was right. The nine-a-day cost was local merges and rebases, and that cost is gone: four branches have rebased onto the driver with zero CHANGELOG conflicts since it landed.
What it changes is the instruction. A contributor who sees
CONFLICTINGon their PR must rebase locally and push. Clicking "Update branch" on GitHub, or waiting for the button, gets them the conflict the driver exists to remove. That is worth writing down, because the failure is confusing in the specific way that costs time: the tree merges cleanly on their machine and the web UI says it does not.Options
I would take 1. The badge is wrong rather than harmful, and the measurement above is the thing a confused contributor needs.
Filed rather than left in a thread because #1108's body asked the question explicitly and the answer belongs where someone will find it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NhwXKAgSmYDUjteWkfajHK