Feature: Git Worktree Support for Multi-Branch Workflows

[theepicsaxguy]

Related to: #57
This could be implemented after that issue has been closed.

---

Problem

OpenCode Manager currently limits users to working in a single branch per repository. This forces users to:

• Stash or discard changes when switching branches.
• Clone multiple copies of the same repo to work on multiple PRs/hotfixes.
• Manually manage branches via the agent (token waste, no native UX).

Git worktrees solve this by allowing multiple working directories linked to a single repository, enabling:

• Parallel work on multiple branches/PRs without stashing.
• Isolation of changes (e.g., one worktree per PR).
• Easy cleanup (delete worktrees when done).

---

Scope

Core Functionality

• Add worktree support to the existing Git UI (post-Allow git actions #57):
  • Create worktrees: From the branch dropdown or Git panel, allow users to create a worktree for a branch (e.g., "Open in Worktree").
  • List worktrees: Show active worktrees in the repo sidebar (e.g., "Worktrees (2)").
  • Delete worktrees: Remove worktrees from the UI (cleans up the filesystem and database).
• Leverage existing Git infrastructure:
  • Reuse the Git credentials/identity from Settings (no re-entry).
  • Use the same Git status/diff/log UI as the main repo.
• Surface worktree-specific states:
  • Highlight the current worktree in the UI (e.g., "PR-123 (worktree)").
  • Show worktree-specific branch status (ahead/behind/conflicts).

UI/UX

• Repo sidebar:
  • Add a "Worktrees" section under the repo name, listing active worktrees.
  • Show the branch name and status (e.g., "PR-123 • 2 ahead, 1 behind").
• Branch dropdown:
  • Add a "Create Worktree" option when right-clicking a branch.
• Git panel:
  • Show worktree-specific actions (e.g., "Delete Worktree").
  • Display the worktree path (e.g., /workspace/repos/opencode-manager/PR-123).

Non-Goals

• Worktree-specific settings: No per-worktree Git credentials or identities.
• Advanced worktree management: No pruning, moving, or locking worktrees.

---

Acceptance Criteria

1. Worktree Creation:

   • From the branch dropdown, I can create a worktree for any branch (local or remote).
   • The worktree is listed in the repo sidebar under "Worktrees".
   • The worktree opens in a new tab with the same Git panel UI as the main repo.

2. Worktree Management:

   • From the repo sidebar, I can:
     • Switch between worktrees and the main repo.
     • Delete a worktree (removes it from the filesystem and UI).
   • The Git panel shows worktree-specific actions (e.g., "Delete Worktree").

3. Worktree States:

   • The UI shows:
     • The current worktree’s branch and status (e.g., "PR-123 • 2 ahead").
     • The worktree path (e.g., /workspace/repos/opencode-manager/PR-123).
   • Worktree changes are isolated (staging/committing in one worktree doesn’t affect others).

4. Error Handling:

   • If a worktree creation fails (e.g., branch doesn’t exist), show a clear error (e.g., "Branch 'feature-x' not found").
   • If a worktree deletion fails (e.g., locked files), show a toast with the error and offer a "Force Delete" option.

5. Backward Compatibility:

   • Existing repos without worktrees continue to work as before.
   • Worktrees are optional (users can ignore them if they prefer single-branch workflows).

---

Design Notes

UI Inspiration

• VS Code:
  • Worktrees appear in the Source Control panel under a "Worktrees" section.
  • Right-click a branch → "Open in Worktree".
• GitKraken:
  • Worktrees are listed in the left sidebar with branch status.

Technical Notes

• Git Worktree Commands:
  • git worktree add <path> <branch>: Create a worktree.
  • git worktree list: List worktrees.
  • git worktree remove <path>: Delete a worktree.
• Filesystem Layout:
  • Worktrees are stored in /workspace/repos/<repo-name>/<worktree-name>.
  • Example: /workspace/repos/opencode-manager/PR-123.
• Database:
  • Extend the Repo model to track isWorktree, baseRepoId, and worktreePath.
  • Worktrees are treated as "lightweight repos" in the UI but share the same Git history.

Edge Cases

• Worktree Already Exists: Show an error if the worktree path already exists.
• Base Repo Deleted: Prevent deleting the base repo if worktrees exist (or offer to delete them first).
• Worktree Branch Deleted: Show a warning if the worktree’s branch is deleted (e.g., "Branch 'feature-x' no longer exists").

I think this could improve the functionality by a lot.