Parallelize VCS calls in list_workspace_entries via thread scope

[drivasperez]

Summary

Refactor list_workspace_entries_inner to parallelize per-workspace VCS operations using std::thread::scope. This reduces latency when listing workspaces by running independent VCS subprocesses (diff_stat_vs_trunk, latest_description, is_merged_into_trunk) concurrently across workspaces.

Key Changes

• Introduce EntryCandidate and ComputedEntry structs to separate candidate collection from parallel computation:

  • EntryCandidate holds workspace metadata and VCS info collected upfront
  • ComputedEntry holds per-workspace fields computed in parallel (diff_stat, description, modified time, is_stale)

• Parallelize VCS calls via std::thread::scope: Each workspace candidate spawns a thread that independently runs up to 3 VCS subprocesses. These are independent across workspaces and dwarf the cost of thread spawning.

• Optimize trunk branch detection: Add OnceLock-based caching to GitBackend to memoize detect_trunk() result. Since trunk is invariant for a single dwm invocation, this avoids redundant git subprocess calls across multiple workspaces.

• Extract stale_by_mtime() helper: Separate mtime-based staleness check from compute_is_stale() to allow skipping the expensive is_merged_into_trunk VCS call when inactivity alone marks a workspace stale.

• Make VcsBackend trait Send + Sync: Required to pass backend references across thread boundaries in the scope.

• Update GitBackend to Default: Change from unit struct to #[derive(Default)] struct to support the trunk cache field.

Implementation Details

• The thread scope collects all workspace candidates first (main workspace + subdirs under .dwm/worktrees/), then fans out VCS calls in parallel
• Each thread captures immutable references to the backend and main repo path, avoiding data races
• Staleness computation is optimized: if a workspace is already stale by mtime (>30 days), skip the merged probe subprocess
• All test instantiations of GitBackend updated to use GitBackend::default()
• Added unit tests for stale_by_mtime() and trunk cache behavior

https://claude.ai/code/session_011a8xba7hxCYzTrxA5LULBQ

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	dwm	e9fb68d	May 21 2026, 10:33 AM

[drivasperez]

Pushed two fixes for the review and CI:

• src/git.rs:143 "We don't need this comment" — removed in 427a53d.
• CI clippy failure — CI is on Rust 1.95 which promoted unnecessary_sort_by into the default lint set. The pre-existing sort_by in src/tui.rs:166 (from PR Feat/dwm extensions #7) and a useless_conversion in my new parallelised list path were tripping it. Both fixed in 427a53d / e9fb68d.

Re. src/git.rs:108 "Can this use LazyLock?" — LazyLock's initializer is fixed at struct-construction time, but detect_trunk(dir) needs the worktree path which only becomes available when the methods are called later (each GitBackend is built by VcsType::to_backend / vcs::detect with no dir argument). I could plumb the repo root onto the struct at construction and use a custom-closure LazyLock, but that means restructuring vcs::detect and VcsType::to_backend — a noticeably bigger diff. OnceLock keeps the change localised to GitBackend while still being thread-safe and lazy. Happy to do the bigger refactor if you'd prefer it.

---

Generated by Claude Code