When a worktree's directory is deleted out from under Fork (common with worktrees under /tmp, which the OS reaps), Fork silently omits the worktree from its UI — but git still considers the branch checked out by that dead worktree entry, so deleting the branch fails with no explanation visible in Fork.
Repro:
- Create a worktree in a temp location:
git worktree add /tmp/wt-foo my-branch
- Delete the directory (or let the OS clear
/tmp): rm -rf /tmp/wt-foo
- In Fork, the worktree no longer appears in the sidebar.
- Try to delete
my-branch in Fork → it fails / the branch appears stuck, because git still holds the checkout lock from the orphaned worktree registration in .git/worktrees/.
git worktree list reports the entry as prunable; git worktree prune clears it and the branch then deletes normally.
Expected: Fork should surface prunable/stale worktrees rather than hiding them — e.g. show them dimmed as "missing" with a prune action, or reconcile them (equivalent to git worktree prune) when it detects the directory is gone, so branch deletion isn't silently blocked.
This is a different symptom of the same underlying gap as #2679 (there, the stale worktree triggers a loud "contact support" error; here it's a silent hide plus a hidden branch-delete block). Both would be resolved by pruning stale worktree references.
Environment: Fork for Mac 2.69.0 / macOS. Worktree directory under /private/tmp.
When a worktree's directory is deleted out from under Fork (common with worktrees under
/tmp, which the OS reaps), Fork silently omits the worktree from its UI — but git still considers the branch checked out by that dead worktree entry, so deleting the branch fails with no explanation visible in Fork.Repro:
git worktree add /tmp/wt-foo my-branch/tmp):rm -rf /tmp/wt-foomy-branchin Fork → it fails / the branch appears stuck, because git still holds the checkout lock from the orphaned worktree registration in.git/worktrees/.git worktree listreports the entry asprunable;git worktree pruneclears it and the branch then deletes normally.Expected: Fork should surface prunable/stale worktrees rather than hiding them — e.g. show them dimmed as "missing" with a prune action, or reconcile them (equivalent to
git worktree prune) when it detects the directory is gone, so branch deletion isn't silently blocked.This is a different symptom of the same underlying gap as #2679 (there, the stale worktree triggers a loud "contact support" error; here it's a silent hide plus a hidden branch-delete block). Both would be resolved by pruning stale worktree references.
Environment: Fork for Mac 2.69.0 / macOS. Worktree directory under
/private/tmp.