The extra one is the merge commit. Every PR lands on main as two commits, the PR's own commit plus "Merge pull request
#110", and the two numbers count them differently.
"Behind origin/main" comes from `git rev-list --left-right --count HEAD...origin/main` in AppUpdate.php, which counts every commit, merges included. The Incoming list comes from `git log --no-merges HEAD..origin/main`, which skips merges on purpose (the comment there says they only repeat what the merged commits say). In your screenshot that's 5ff0a547 plus a2bcc64d, the merge of
#110. Two PRs waiting would show 4 behind and 2 incoming.
Nothing is wrong, but it reads like a bug, so I'd fix the label rather than the number. Changing `behind` itself is riskier: it decides "up to date", and a checkout can in principle be behind by a merge commit alone, so a merges-excluded count could say 0 when a deploy would still move HEAD. Two cheap options:
1. Show the split: "2 commits (1 change + 1 merge)". AppUpdate already has the no-merges count, so it's one extra field and a tweak in templates/pages/deploy.php and deploy_control.js (which refreshes the field live).
2. Squash-merge PRs on GitHub. Then there are no merge commits and the numbers match on their own, but you lose the "Merge pull request #N" markers in the log.
I'd go with 1. Happy to open the PR.
#meta