Found while implementing #9747 (PR #9875), whose dispatch asked for a churn measurement "the way #9680's dev did it". Recording only; nothing is fixed by this card.
The measurement disagreement
| source | commits on main in the month to 2026-08-18/19 |
|---|
| PR #9712 (card #9680), used to price a delta-ratchet | 269 |
this container, after git fetch --shallow-since=2026-07-18 | 3,195 first-parent (3,231 including merge parents) |
Why
The clone this container starts with is shallow:
$ git rev-parse --is-shallow-repository
true
$ git rev-list --count origin/main
63
$ git log origin/main --format='%ad' --date=short | sort | uniq -c
37 2026-08-18
26 2026-08-19
Two days of history. git rev-list --count origin/main --since=<a month ago> on that clone answers with however many of the 63 fall in the window — a number that is real, plausible, and has nothing to do with the repo. git log --since gives no warning that its input is truncated; the grafted boundary is silent.
git fetch --shallow-since="2026-07-18" origin main takes 15 seconds and brings the count to 3,290. Every history question has to be asked after that, not before.
Why it matters beyond one PR body
Churn rates are load-bearing evidence in this repo right now: #9680's "269 commits, membership changed in 7 (2.6%), 0 left" is the argument that a delta-ratchet is free, and #9747's ruling makes the nuisance rate the gate on generalizing the whole direction. A denominator that is 12x too small does not change that particular conclusion's direction (the leave count was 0 either way), but it makes every such percentage unverifiable, and the next one may not be so lucky.
This is #9747's own shape, one layer out: an instrument reporting a small, clean-looking number because it could only see part of the population, with nothing in the output saying so.
What a fix could look like (not proposed, just sized)
- the cheapest: a line in AGENTS.md's measurement guidance — before any
--since question, check git rev-parse --is-shallow-repository and deepen; - or a tiny
scripts/pm/ helper that deepens and then answers, so the deepening cannot be forgotten; - or the container image fetching unshallowed for repos of this size.
Prior art, both closed, both the same class of hazard: #9555 (a pnpm run version rehearsal hangs forever in a shallow clone) and #9408 (bump-objectui.sh's walkability guard cannot detect a shallow objectui clone and ships a complete-looking record derived from truncated history). Two prior instances plus this one make it a small family rather than a one-off.
Related: #9747 · #9680 / PR #9712 · PR #9875 · #9555 · #9408
Generated by Claude Code
Found while implementing #9747 (PR #9875), whose dispatch asked for a churn measurement "the way #9680's dev did it". Recording only; nothing is fixed by this card.
The measurement disagreement
mainin the month to 2026-08-18/19git fetch --shallow-since=2026-07-18Why
The clone this container starts with is shallow:
Two days of history.
git rev-list --count origin/main --since=<a month ago>on that clone answers with however many of the 63 fall in the window — a number that is real, plausible, and has nothing to do with the repo.git log --sincegives no warning that its input is truncated; the grafted boundary is silent.git fetch --shallow-since="2026-07-18" origin maintakes 15 seconds and brings the count to 3,290. Every history question has to be asked after that, not before.Why it matters beyond one PR body
Churn rates are load-bearing evidence in this repo right now: #9680's "269 commits, membership changed in 7 (2.6%), 0 left" is the argument that a delta-ratchet is free, and #9747's ruling makes the nuisance rate the gate on generalizing the whole direction. A denominator that is 12x too small does not change that particular conclusion's direction (the leave count was 0 either way), but it makes every such percentage unverifiable, and the next one may not be so lucky.
This is #9747's own shape, one layer out: an instrument reporting a small, clean-looking number because it could only see part of the population, with nothing in the output saying so.
What a fix could look like (not proposed, just sized)
--sincequestion, checkgit rev-parse --is-shallow-repositoryand deepen;scripts/pm/helper that deepens and then answers, so the deepening cannot be forgotten;Prior art, both closed, both the same class of hazard: #9555 (a
pnpm run versionrehearsal hangs forever in a shallow clone) and #9408 (bump-objectui.sh's walkability guard cannot detect a shallow objectui clone and ships a complete-looking record derived from truncated history). Two prior instances plus this one make it a small family rather than a one-off.Related: #9747 · #9680 / PR #9712 · PR #9875 · #9555 · #9408
Generated by Claude Code