Check upstream before you patch: the three-command version-skew check

Before you patch a bug in the tool you run, find out whether upstream already fixed it. Three git commands tell you how far behind you are and whether your fix already exists.

My agents found two real bugs in Hermes, the tool they run on. The fixes went upstream as PR #83197 and PR #83199, both still open: one for a scheduled job that delivered with the wrong bot identity under multiplexing — several profiles sharing one gateway — and one for orchestrator replies landing in the wrong Telegram topic, whose removal story lives in hermes-17. What belongs in every toolbox is the check I ran before writing either patch: is this bug already fixed upstream?

When you finish, you can answer that with three git commands — how far behind upstream am I, and is the fix already written? — before you patch anything locally.

Why the check comes first

Running software from a git checkout means running a snapshot. Upstream moves; your checkout does not. So the bug in front of you is one of two things: already fixed in a commit you do not have, or genuinely new and worth reporting. The check tells you which in about ten seconds, and it decides your whole move — pull the fix, or write one. Patching first is the expensive order: you hand-fix a bug, carry the patch forever, and only later discover the upstream commit that would have saved you the work.

The three-command check

git fetch origin
git log --oneline HEAD..origin/main | wc -l   # how far behind are you?
git log --oneline origin/main --grep="<your bug>"   # is it already fixed?

Fetch brings down the latest refs. The second line counts the upstream commits you do not have — that is your skew, the gap between your snapshot and main. Zero means you are current. Hundreds means you are a snapshot of something old. The third greps upstream’s history for your bug’s keyword. A result means the fix exists: pull it or cherry-pick it and skip the local patch. No result means new ground: report it, or send a PR.

The gap is the warning light. When my fleet found the first bug, the checkout sat 1,025 commits behind upstream main — the bigger the skew, the more likely the bug you are about to fix by hand is already fixed by someone else.

The takeaway

A local patch for a bug upstream already fixed is how forks drift — a fork being a copy that has stopped tracking upstream. Check upstream before patching locally. Three commands, ten seconds, and you know whether your work is a fix or a duplicate.