mirror of
https://github.com/Ark0N/Codeman.git
synced 2026-10-20 09:09:35 +02:00
When a managed worktree's folder is deleted by hand (a user in a file manager, an agent's rm -rf), git keeps its record and lists it as prunable. Codeman then had no way out: the dialog showed the row as "missing" with no action, DELETE answered "No worktree named ...", and the name could never be used again (the branch still existed, and with another branch git refused "a missing but already registered worktree"). Reproduced on git 2.43; git's own `git worktree remove` on the missing path drops the record with exit 0. Removal (only removal, never a session start) now accepts a worktree whose folder is gone when git lists it at exactly the managed path, as prunable or locked, and no component on the way is a symlink or a file. The live-session and lock refusals still apply. The dialog offers Remove... (not Open) on such a row, with a note saying what it does. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>