[max-sixty]

wt list and the picker open their task pool only once the post-skeleton ref snapshot is built. That snapshot rescanned refs/heads/, which the phase before the skeleton had already scanned into the cached branch inventory, and then refs/remotes/, one after the other. In the picker the preview panes' comparison base ran the same pair of scans a third time.

Repository::inventory_snapshot(base) replaces capture_refs_with_ahead_behind and builds the snapshot from the cached inventories, scanning only one that nobody has fetched yet. Tasks now resolve refs to the same SHAs the rows were built from. The comparison base builds its snapshot the same way, and the Remote⇅ upstream primer reads the same inventories, so it runs beside the snapshot instead of after it. capture_refs still scans fresh, and every command that moves a ref keeps using it; the docs that pointed at "a RefSnapshot captured at the moment of read" now name it.

The phase before the skeleton still scans refs/remotes/ only when remote rows are shown. Doing it unconditionally would make first paint wait on it in a repo with many remote branches and few worktrees, so plain wt list runs that scan once, after the skeleton.

Measured on a repo with 50 worktrees, 52 local branches and 103 remote-tracking branches, alternating with main, medians in ms from the start of collect:

	skeleton	task pool opens	last result
wt list, main	58	93	240
wt list, this branch	58	78	221
picker, main	49	120	—
picker, this branch	38	47	—

for-each-ref scans per run went from 3 to 2 for wt list and from about 4.4 to 2 for the picker. The picker's skeleton difference is likely noise; nothing before its skeleton forks less.

inventory_snapshot_reuses_cached_inventories checks that the snapshot reads the cached scans; the existing ahead-behind tests now run through inventory_snapshot.

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

🤖 Generated with Claude Code