A column that had to be measured before it could exist.
Commits by you, per repository, over the last year
Set commit_counts = true — or flip Commit counts in the settings
panel (,) — and the Repos tab gains a Commits column: how many
commits you authored on each repository's default branch in the last
365 days, with its own sort in the s cycle and in default_sort.
It answers a question the per-repo drill-in could not: not "how much did
I commit here?" but "which of my repositories do I actually commit to
most?", in one ordering across the whole list.
It is off by default, and the reason is a number rather than a taste.
Why it is opt-in
GitHub counts each repository's history on request. Asked for inline on
the query that already feeds the Repos tab, that count pushed the query
from 6.5 seconds to somewhere between 8 and 11 on a 91-repository
account — past GitHub's 10-second processing limit three times in five.
The first run passed, at 9.8 seconds. A single green run of a query that
close to the clock proves nothing.
So the column runs as a query of its own, in parallel with the six the
dashboard already makes, paging at 50 repositories rather than 100. On
that same account it takes four to six seconds, which is a cost every
refresh pays and only some accounts will want. It is also best-effort
by construction: if it ever times out, you lose the column for one
refresh — the header falls back to the previous sort and says so — and
never the dashboard. A timeout on GitHub's side is not free either (the
rate limit is docked for the following hour), which is one more reason
the branch prefers small requests to one that flirts with the cut-off.
The column needs an authenticated viewer to attribute commits to, so on
someone else's public profile it stays hidden rather than showing a
column of zeros. And a zero, when the column is on, is a real zero: the
tab distinguishes "you made no commits here" from "the count did not
arrive".
The settings toggle does what the file could not
Flipping Commit counts in the panel sets the flag and refetches at
once, in either direction, so the column appears — or goes — without
waiting for the next tick. If a refresh is already running when you
save, the toggle is remembered and one more fetch follows the moment it
lands, so what you see is a result taken after the change, never one
that happened to read the old setting on its way out.
--json
Repositories carry commits_last_year when the column is on: an
explicit 0 where you made no commits, and the key absent entirely
when the count was not fetched — so a script can tell the two apart.
Watched repositories never carry it; the branch counts only what you
own.
Under the hood, for the curious
The contributor guide had described this limit as a "complexity budget"
since v0.10.1. Measuring it showed a clock: rateLimit.cost read 1 for
every query shape, the ones that survived and the ones that died alike.
The guide now says so, along with the two numbers that decide what can
be added to the list fetch — it already spends about 6.5 of the 10
seconds on a busy account, and a first run that passes near the limit
is the coin landing heads.
Tests
Hermetic tests cover the merge by owner/name, the N-way rate-limit
fold, the query's page size and variables, the sort cycle skipping the
column when it is off, the fallback when counts did not arrive, the
JSON contract, and the settings toggle applying both halves of the flag
and refetching once. Every one was proven to fail by breaking what it
guards and restoring it; the toggle's mid-fetch path runs under the race
detector in CI.
Upgrade
brew upgrade gfazioli/tap/octoscope
Or gh extension upgrade octoscope, go install github.com/gfazioli/octoscope@latest,
or pull ghcr.io/gfazioli/octoscope:latest.