You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today the worktree inventory is Tauri-only: the logic lives in src-tauri/src/worktrees.rs, so arrow --worktrees from the terminal is not possible. The CLI (src/main.rs + the arrow lib) is a separate crate and can't import the Tauri backend. This proposes a small architecture move so the same inventory can back both the app and the CLI, without compromising the "parser stays git-free" premise.
Why
The CLI is great for scripting disk hygiene (arrow --worktrees --json | …) and for headless/SSH boxes where the GUI isn't available — the same audit the modal shows, in a pipe.
Proposed shape
Move the worktree audit out of src-tauri/src/worktrees.rs into a separate, opt-in module in the shared lib (e.g. src/worktree.rs) that the parser never calls — build_report/file_content stay 100% git-free. This mirrors the separation already used for the new update-check layer in Tell the user when a newer release exists (check-for-updates) #9 (an opt-in secondary layer that shells out, kept off the parser hot path).
src-tauri keeps its thin #[tauri::command] wrappers but delegates to the shared module (no logic duplication).
Add --worktrees [--json] [--no-sizes] to src/main.rs, rendering the same RepoWorktreesOut contract the UI consumes.
Honesty / scope
The git shelling stays argv-direct, read-only, time-boxed — exactly as it is now. Only its location changes (lib module vs Tauri-only), gated so the core parser remains git-free.
Sizes stay opt-in (du/walkdir is the one slow part); --no-sizes skips them for a fast scan.
Question
Would you prefer (a) consolidating into a shared opt-in module so the CLI and app share one implementation, or (b) keeping worktrees strictly Tauri-only? I'm happy to send the PR for (a) if that's acceptable — I have a working implementation to adapt. Related: #8 (worktree Clean) and #9 (check-for-updates) follow the same "opt-in secondary layer, parser stays pure" pattern.
Today the worktree inventory is Tauri-only: the logic lives in
src-tauri/src/worktrees.rs, soarrow --worktreesfrom the terminal is not possible. The CLI (src/main.rs+ thearrowlib) is a separate crate and can't import the Tauri backend. This proposes a small architecture move so the same inventory can back both the app and the CLI, without compromising the "parser stays git-free" premise.Why
The CLI is great for scripting disk hygiene (
arrow --worktrees --json | …) and for headless/SSH boxes where the GUI isn't available — the same audit the modal shows, in a pipe.Proposed shape
src-tauri/src/worktrees.rsinto a separate, opt-in module in the shared lib (e.g.src/worktree.rs) that the parser never calls —build_report/file_contentstay 100% git-free. This mirrors the separation already used for the new update-check layer in Tell the user when a newer release exists (check-for-updates) #9 (an opt-in secondary layer that shells out, kept off the parser hot path).src-taurikeeps its thin#[tauri::command]wrappers but delegates to the shared module (no logic duplication).--worktrees [--json] [--no-sizes]tosrc/main.rs, rendering the sameRepoWorktreesOutcontract the UI consumes.Honesty / scope
du/walkdir is the one slow part);--no-sizesskips them for a fast scan.Question
Would you prefer (a) consolidating into a shared opt-in module so the CLI and app share one implementation, or (b) keeping worktrees strictly Tauri-only? I'm happy to send the PR for (a) if that's acceptable — I have a working implementation to adapt. Related: #8 (worktree Clean) and #9 (check-for-updates) follow the same "opt-in secondary layer, parser stays pure" pattern.