13 of 18 merge conflicts between parallel branches were the changelog

Two coding agents finish two branches. Both touched one file, and one of them has to wait. I wanted to know how often that file is actually code. So I took a public Rust project that coordinates parallel coding agents, Foremerge, and replayed its history.

What I tried

Foremerge has 42 merged pull requests. 27 pairs were open at the same time and changed a common file. I merged each pair’s two heads with git’s merge-tree, which writes no files and moves no branch:

git merge-tree --write-tree <head-a> <head-b>

18 of the 27 pairs conflicted.

What actually happened

13 of those 18 conflicts were in CHANGELOG.md and nowhere else. Both branches had added an entry at the same spot. The code merged fine.

Then I told git the changelog is append-only:

echo 'CHANGELOG.md merge=union' >> .gitattributes

Rerun: 5 conflicts left, all in real files. A coworker agent ran cargo fmt, build and test on the 13 newly clean trees. 12 passed.

The 13th looked like the jackpot: both branches pass alone, they merge without a conflict, and the combination does not compile, because a constant and a function are defined twice. I checked before writing it up. It was my test’s fault. One pull request had been squash-merged. The other had later pulled main in, so it carried the same change under a different commit. Merging the two heads on their old merge base adds it twice. On the real main it never happened.

What you can use

1. Count before you build anything. git merge-tree over your last 40 pull requests takes minutes and tells you whether your collisions are code or bookkeeping.
2. If it is the changelog, merge=union clears it for local merges. Two catches. Union is line-based, so in one pair it left a duplicate “### Added” heading. And a maintainer reports in an open issue (https://github.com/laurigates/claude-plugins/issues/2947) that GitHub’s own merge, Update branch and mergeability check ignore merge drivers, while a local merge of the same branches went through. I have not tested GitHub’s side. One file per change, rendered into the changelog by a script, avoids both.
3. If you test pairs of branches, drop pairs where one already contains the other’s landed change. Otherwise squash merges hand you failures that never existed.

The numbers: 42 pull requests, 27 overlapping pairs, one replay on 3 Nov 2026. I reproduced the merges and the false positive myself. The cargo results are the coworker’s, from one run without --all-features.