When using git worktree with Fork, deleting a worktree and then switching back to Fork triggers a large, blocking error alert in the app:
Unexpected error:
open object db '/Users/is/work/proj/.git/worktrees/brainforce.docs'
open '/Users/is/work/proj/.git/worktrees/proj.docs/objects'. Path does not exist
Please contact Fork support
This is incorrect and misleading. Worktrees are transient by design — they are temporary working directories that developers routinely create and delete as part of normal Git workflows (feature branches).
Fork should not treat a missing worktree as a critical error that requires user action or support intervention. Instead, it should:
- Silently ignore missing worktree paths when refreshing the repository state.
- Automatically prune stale worktree references from its internals.
- Never display a full‑screen alert with a "contact support" message for this scenario.
Personally I think this should work for any cloned repo (not necessarily a worktree); but for worktrees it's especially critical.
When using git worktree with Fork, deleting a worktree and then switching back to Fork triggers a large, blocking error alert in the app:
This is incorrect and misleading. Worktrees are transient by design — they are temporary working directories that developers routinely create and delete as part of normal Git workflows (feature branches).
Fork should not treat a missing worktree as a critical error that requires user action or support intervention. Instead, it should:
Personally I think this should work for any cloned repo (not necessarily a worktree); but for worktrees it's especially critical.