[max-sixty]

Follow-up to #3676, which made wt list's table render git's %h instead of &head[..8]. The --prs log tab was the last user-visible fixed-8 abbreviation.

The defect

wt switch --prs renders a row's log tab from the local git log when the PR head is in the object store, and from gh pr view <n> --json commits / glab api …/commits when it isn't. The forge path sliced each SHA to 8 characters, so on a repo where git abbreviates to 9 the same commit read abc1234 at 8 before a fetch and 9 after, and core.abbrev never reached the pane at all.

The fix

Repository::abbrev_len asks git how wide it abbreviates in this repo and caches the answer on RepoCache, so a picker with 30 PR rows probes once — clones share the Arc<RepoCache>, and once_cell::sync::OnceCell collapses the concurrent background rows onto one fork.

The pane wants the width rather than short_sha because of the branch it sits on: it runs precisely when the head isn't local, and git rev-parse --short takes a single revision — there is no batched form for a list of absent commits, and looping it would be one subprocess per commit per row. With no objects to disambiguate against, the width is git's whole answer for these SHAs.

Both forge arms now parse the full SHA and share one abbreviation step in render_commit_lines. GitLab's ready-made short_id goes unused: it's the server's abbreviation, blind to the reader's core.abbrev, and taking it printed an MR's commits at a different width from a PR's.

The audit

#8 claimed the --prs tab was the last one; that came from a grep. Sweeping .take(N), [..N], {:.N}, truncate(N), get(..N), and --abbrev/--short= across src/ turned up one more user-visible case: wt config state's CI cache table, which sliced cached.head to 8 and now truncates to abbrev_len.

One fixed-width slice over a SHA survives deliberately: collect/tasks.rs labels a tracing::debug! line with &sha[..8] as a fallback when a timed-out task has no branch name. It's a trace field rather than rendered output, and the timeout error path is the wrong place to spawn git.

Everything else the sweep found hashes something other than a git object — config::short_hash's base36 branch suffix, summary.rs's content digest — or is a column width rather than a truncation.

Cost

Both call sites are flat in the number of SHAs: one git rev-parse --short HEAD per repo per process.

The first cut of the CI table called short_sha per row instead, to keep git's extension of an ambiguous prefix. That's a fork apiece, and it cost more than the whole command was worth — measured on a repo with a cache entry per branch, wt config state get at 50 entries:

wt config state get, 50 cache entries, release build, hyperfine (warmup 20, 80+ runs, quiet machine):

	mean ± σ	vs. baseline
before this PR (.take(8))	22.1 ± 0.8 ms	—
abbrev_len (this PR)	26.1 ± 1.3 ms	+4.0 ms, 1.18× ± 0.07
short_sha per row	266.7 ± 3.9 ms	12×

The +18% is one git rev-parse --short HEAD against a command whose entire
runtime is ~22 ms. For scale, a trace of the same command shows gh --version
at 15.3 ms and git config --list -z running three times for ~12 ms, both of
which predate this PR. The probe sits inside the non-empty branch, so a repo
with no CI cache pays nothing.

No Criterion target covers wt config state (time_to_first_output covers
remove/switch/list; picker_preview covers worktree rows, not --prs,
which needs a forge CLI), hence the standalone measurement. Worth noting against
the daily suite's own resolution: run-to-run spread on an unchanged bench
(worktree_scaling/warm/8, last 10 nightlies) is 18%, so a benchmark would not
have caught the +18% either — though it would have caught the 12×.

So the form here pays one probe and gives up disambiguation. Absent objects have nothing to collide with, and a live collision at 7–9 characters is rare enough for a display column to wear.

On the picker, abbrev_len lands on a background pool thread behind a gh/glab call that costs orders of magnitude more, and never on a first-paint path.

#3676 itself cost nothing at runtime, for the record: %h was already in the pre-skeleton git log --no-walk batch (%ct from the same fork drives row order), and the format string is byte-identical across that commit. It moved where the already-fetched string is copied onto the row and swapped a COMMIT_HASH_WIDTH = 8 constant for an O(N) width pass over the rendered SHAs. No fork added, no phase reordered — the pre-skeleton budget table in collect/mod.rs reads 23 commands on both sides.

Tests

• abbrev_len_follows_core_abbrev_and_covers_absent_objects — the width matches %h, core.abbrev = 12 reaches it, and it equals what git gives for a SHA with no object behind it.
• render_commits_abbreviates_to_the_given_width — the pane prints the width it's handed, at 7 and at 12.
• parse_gitlab_commits_keeps_order_and_takes_the_full_id — id over short_id.
• test_state_get_ci_head_uses_git_abbreviation — the CI table's Head cell equals git rev-parse --short. It can't be a snapshot: the width scales with the repo's object count and a test repo's SHA isn't fixed.

cargo run -- hook pre-merge --yes: 4494 passed.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

Reviewing as a draft — flagging anything that looks worth a quick fix. Mark ready for a full review.

The change is clean and the audit is convincing — the split into parse_* + render_commit_lines reads well, and the tests pin the width behavior end to end. One small doc-accuracy nit inline; nothing blocking.

[worktrunk-bot]

The refactor is clean — splitting parse_* from render_commit_lines and probing the width once via abbrev_len reads well, the once_cell::sync::OnceCell collapse of concurrent picker rows onto one fork checks out, and the tests pin the width behavior (git's abbreviation, absent-object case, core.abbrev reach) end to end. The CI-cache-table find from the audit is a nice catch.

One non-blocking nit inline: the code comment's perf figures don't match the PR body's benchmark table for the same scenario.