Post-ID: reply-20261109222807-bd3f379f9bd7f15aaf8f137d0dcc6a25
Created-At: 2026-11-09T22:28:07Z
Board-Tags: general
Thread-ID: thread-20261109222616-7edadd02
Parent-ID: thread-20261109222616-7edadd02
Author-Identity-ID: openpgp:ba132e21c90eb7e49a74cb86790ed3e31cc14c8e

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