Add global worktree directory support

[olinguyen]

I'm mainly looking for feedback. This is my first time working in a Rust codebase 🥲

Screen.Recording.2025-12-31.at.11.26.52.PM.mov

Summary

Add support for managing worktrees across multiple projects from a central directory.

• New config option: global-worktree-dir places all worktrees in one location using {project}.{branch} naming
• New flag: wt list --global discovers and lists worktrees across all projects, grouped by repository

Motivation

When working on multiple projects, I wanted to keep all worktrees in a single directory (~/worktrees/) rather than scattered as siblings to each repo. This makes it easy to see everything at a glance and keeps project directories clean.

Before:

~/code/worktrunk/
~/code/worktrunk.feature-auth/
~/code/worktrunk.bugfix-123/
~/code/other-project/
~/code/other-project.feature-x/

After (with global-worktree-dir = "~/worktrees"):

~/code/worktrunk/
~/code/other-project/
~/worktrees/worktrunk.feature-auth/
~/worktrees/worktrunk.bugfix-123/
~/worktrees/other-project.feature-x/

Usage

# ~/.config/worktrunk/config.toml
global-worktree-dir = "~/worktrees"

$ wt switch --create feature-auth    # Creates ~/worktrees/myrepo.feature-auth/
$ wt list --global                   # Lists worktrees from all projects

Design decisions

• Discovery: Scans for .git files (not directories) to find linked worktrees, then groups by parent repository
• Naming: Uses repo name from project_identifier() (e.g., worktrunk not github.com/user/worktrunk) for readable directory names
• Backwards compatible: Without config, behavior is unchanged
• Flag conflicts: --global conflicts with --branches/--remotes since those are repo-specific

Test plan

• wt list --global when not configured → helpful error message
• wt list --global when directory doesn't exist → error
• wt list --global with empty directory → "No worktrees found"
• End-to-end: create worktree in global dir, list it, switch to it
• JSON output includes project and project_path fields
• Help text and docs updated

[olinguyen]

@max-sixty wanted to get your thoughts on this idea

[max-sixty]

I think it's quite interesting! I definitely think it would be cool to be able to see an overview of all current "workstreams" that someone is working on.

nothing decisive, but my sense is that the worktrunk library might not be the best place for it — lots of wt list relies on being in a single repo. and I'm keen to not expand outside worktree management, to anything that could be less robust or compatible

interested if others have views, though

would be very happy to make wt list into a library interface if you want to build something with it too