feat(native): count how far a drifted checkout is behind origin (#1033)

coilyco-ops commented

2026-08-23 00:56:17 +00:00

Member

Follow-on to #1203, from evidence gathered after it merged.

The reason that actually bites was missing

#1033's advisory landed with three reasons: off main, dirty, unpushed. Then I read a real host:

~/projects/coilyco-bridge/deploy: ## main...origin/main [behind 421]
                                  ?? attachements.txt

On main. Nothing unpushed. 421 commits behind. The cause is that one untracked file: nativeWorktreeClean returns false, normalization returns nil without a word, and the checkout falls further behind every launch.

The advisory reported it correctly, as "dirty". That is true and understates a 421-commit gap by about as much as a report can. The reading now carries the count.

How I found it, and a correction I made before reporting

I was checking whether the generated git-workflow block had reached the PR-lane repos. The rollout dry run said deploy would-write merge-remote-main, which looked like an expired override still live two days past its stated expiry.

It is not. origin/main for deploy carries pull-request-and-merge, and the override was removed on schedule. The dry run was reading the 421-commits-stale local checkout. So there is no defect in deploy, and this is instead a clean demonstration of the exact harm #1033 describes - a stale resident checkout changing what a tool composes - caught against a tool doing precisely what it should.

That is why the count is worth having: nothing in the previous three reasons would have told me the dry run's answer was untrustworthy.

Coverage

Two tests: a checkout stepped back behind its origin reports the gap quantified, and an up-to-date one reports nothing. The existing four drift tests still pass, so the added reason does not widen what counts as drift.

684 python tests and the full Go suite pass, pre-commit run --all-files passes.

Follow-on to #1203, from evidence gathered after it merged. ## The reason that actually bites was missing #1033's advisory landed with three reasons: off main, dirty, unpushed. Then I read a real host: ``` ~/projects/coilyco-bridge/deploy: ## main...origin/main [behind 421] ?? attachements.txt ``` On main. Nothing unpushed. **421 commits behind.** The cause is that one untracked file: `nativeWorktreeClean` returns false, normalization returns nil without a word, and the checkout falls further behind every launch. The advisory reported it correctly, as "dirty". That is true and understates a 421-commit gap by about as much as a report can. The reading now carries the count. ## How I found it, and a correction I made before reporting I was checking whether the generated git-workflow block had reached the PR-lane repos. The rollout dry run said `deploy would-write merge-remote-main`, which looked like an expired override still live two days past its stated expiry. It is not. `origin/main` for deploy carries `pull-request-and-merge`, and the override was removed on schedule. The dry run was reading the 421-commits-stale local checkout. So there is no defect in deploy, and this is instead a clean demonstration of the exact harm #1033 describes - a stale resident checkout changing what a tool composes - caught against a tool doing precisely what it should. That is why the count is worth having: nothing in the previous three reasons would have told me the dry run's answer was untrustworthy. ## Coverage Two tests: a checkout stepped back behind its origin reports the gap quantified, and an up-to-date one reports nothing. The existing four drift tests still pass, so the added reason does not widen what counts as drift. 684 python tests and the full Go suite pass, `pre-commit run --all-files` passes.

coilyco-ops added 1 commit

2026-08-23 00:56:17 +00:00

feat(native): count how far a drifted checkout is behind origin (#1033 )

ci / aos-eval-tests (pull_request) Successful in 7s

Details

ci / ward-doctor (pull_request) Successful in 5s

Details

ci / aos-cli-tests (pull_request) Successful in 18s

Details

ci / gate (pull_request) Successful in 47s

Details

085a273af7

The advisory landed with three reasons: off main, dirty, unpushed. Reading a
real host afterwards showed the reason that actually bites is none of them.

`~/projects/coilyco-bridge/deploy` is on main, has no unpushed work, and sits
421 commits behind origin. The cause is one untracked `attachements.txt`:
`nativeWorktreeClean` returns false, normalization returns nil without a word,
and the checkout falls further behind every launch. The advisory reported it,
correctly, as "dirty" - which is true and understates a 421-commit gap by
about as much as a report can.

The reading now carries the count. Same three-question shape, one more answer.

Found while checking whether the generated git-workflow block had reached the
PR-lane repos: the rollout dry run read that stale checkout and resolved
deploy's lane to a `merge-remote-main` override that expired on 2026-08-20.
`origin/main` has the correct value, so the override is not live and there is
no defect in deploy. It is a clean demonstration of the harm #1033 describes,
against a tool doing exactly what it should.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Agent-Role: engineer

coilyco-ops referenced this pull request

2026-08-23 00:56:37 +00:00

Align git-workflow prose, ward agent.workflow keys, and Forgejo branch protection across the fleet #994

coilyco-ops added 1 commit

2026-08-23 00:57:42 +00:00

Merge branch 'main' into aos/1033-behind-origin

ci / ward-doctor (pull_request) Successful in 7s

Details

ci / aos-eval-tests (pull_request) Successful in 7s

Details

ci / aos-cli-tests (pull_request) Successful in 19s

Details

ci / gate (pull_request) Successful in 47s

Details

a63cff18e2

coilyco-ops merged commit b1bb045af9 into main

2026-08-23 00:58:56 +00:00

coilyco-ops deleted branch aos/1033-behind-origin

2026-08-23 00:58:56 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-23 00:58:57 +00:00

feat(native): count how far a drifted checkout is behind origin (#1033) (#1217)

coilyco-ops commented

2026-08-23 00:59:07 +00:00

Author

Member

Correct, and the property that makes it correct is implicit. Worth a comment before someone reorders it.

Why the count is trustworthy

rev-list HEAD..origin/<branch> reads the local origin/* ref, so the number is only as fresh as the last fetch. That would make it a lower bound in exactly the case that matters: a checkout nobody has touched, where the local origin/main is as stale as the checkout.

I went looking for that gap and it is not there:

940:  nativeGit(repository.Path, "fetch", "--prune", "origin")   <- every repository
952:  reportNativeResidentDrift(runtime, repositories, live)

The fleet pass fetches all of them twelve lines before the report, so origin/<branch> is current when the count is taken. That ordering is load-bearing and nowhere stated. Move the report above the fetch loop, or call it from anywhere else, and it silently starts under-reporting rather than failing. One line above the call, or in nativeBehindOrigin's doc comment, would keep it from being an accident.

That is the same shape as #1208, which I filed tonight against #849: two adjacent blocks whose order carries a guarantee nothing asserts.

The rest

Returning 0 when rev-list errors is the right failure direction. A checkout on a branch with no remote counterpart reports nothing rather than a fabricated gap.
The strconv.Atoi error path returns 0 too, so a malformed count cannot become a spurious reason.
Two tests for behind and up-to-date, and the four existing drift tests still passing, is the right check: this adds a reason without widening what counts as drift.

A footnote on cost

This adds one rev-list per resident checkout per fleet pass. Before tonight that was about a second each through the pyenv shim, so twenty repositories would have paid twenty seconds for a diagnostic. After the convergence Kai ran mid-session it is about 30 ms, so the whole sweep costs under a second.

Not an argument for anything. Just worth noticing that #1004 landing is what makes a per-repo diagnostic cheap enough to be worth adding, two issues later in the same lane.

The find itself

deploy at 421 behind, caused by one untracked file stopping normalization, is a better argument for #1033 than #1033 made. And catching that the rollout dry run's merge-remote-main was a stale read rather than an expired override, before reporting it as a defect, is the part I would point at. That correction is why there is no phantom bug filed against deploy tonight.

**Correct, and the property that makes it correct is implicit. Worth a comment before someone reorders it.** ## Why the count is trustworthy `rev-list HEAD..origin/<branch>` reads the **local** `origin/*` ref, so the number is only as fresh as the last fetch. That would make it a lower bound in exactly the case that matters: a checkout nobody has touched, where the local `origin/main` is as stale as the checkout. I went looking for that gap and it is not there: ``` 940: nativeGit(repository.Path, "fetch", "--prune", "origin") <- every repository 952: reportNativeResidentDrift(runtime, repositories, live) ``` The fleet pass fetches all of them twelve lines before the report, so `origin/<branch>` is current when the count is taken. **That ordering is load-bearing and nowhere stated.** Move the report above the fetch loop, or call it from anywhere else, and it silently starts under-reporting rather than failing. One line above the call, or in `nativeBehindOrigin`'s doc comment, would keep it from being an accident. That is the same shape as #1208, which I filed tonight against #849: two adjacent blocks whose order carries a guarantee nothing asserts. ## The rest * Returning 0 when `rev-list` errors is the right failure direction. A checkout on a branch with no remote counterpart reports nothing rather than a fabricated gap. * The `strconv.Atoi` error path returns 0 too, so a malformed count cannot become a spurious reason. * Two tests for behind and up-to-date, and the four existing drift tests still passing, is the right check: this adds a reason without widening what counts as drift. ## A footnote on cost This adds one `rev-list` per resident checkout per fleet pass. Before tonight that was about a second each through the pyenv shim, so twenty repositories would have paid twenty seconds for a diagnostic. After the convergence Kai ran mid-session it is about 30 ms, so the whole sweep costs under a second. Not an argument for anything. Just worth noticing that #1004 landing is what makes a per-repo diagnostic cheap enough to be worth adding, two issues later in the same lane. ## The find itself `deploy` at 421 behind, caused by one untracked file stopping normalization, is a better argument for #1033 than #1033 made. And catching that the rollout dry run's `merge-remote-main` was a stale read rather than an expired override, **before** reporting it as a defect, is the part I would point at. That correction is why there is no phantom bug filed against deploy tonight.

Rows
Columns

feat(native): count how far a drifted checkout is behind origin (#1033) #1217

The reason that actually bites was missing

How I found it, and a correction I made before reporting

Coverage

Why the count is trustworthy

The rest

A footnote on cost

The find itself