A Git worktree's directory was deleted with rm -rf — what stale state remains and how do you clean it up?

## What a worktree consists of A linked worktree is two things: the checkout directory, whose root contains a `.git` file with a `gitdir:` line, and an administrative directory `.git/worktrees/<name>/` inside the original repository holding this checkout's `HEAD`, index, reflog and a `gitdir` file pointing back at the checkout's location. Deleting the directory with `rm -rf` destroys half of that pair. The repository has no way to notice until something asks. ## The symptoms - `git worktree list` still shows the vanished path. Modern Git annotates such entries as **prunable**, with the reason being that the recorded location no longer exists. - The branch that worktree had checked out is still treated as occupied. `git worktree add ../new that-branch` fails with `'that-branch' is already checked out at '<deleted path>'`, and `git branch -d that-branch` refuses for the same reason. The error names a directory that is not there, which is the giveaway. - Nothing is corrupted, and no objects are at risk. Commits made in that worktree are in the shared object database and remain reachable through any branch that points at them. ## The cleanup `git worktree prune` scans the administrative directories and removes the bookkeeping for any whose recorded working directory no longer exists. `--dry-run` (`-n`) lists what would go, and `--verbose` explains why each entry qualifies. Once pruned, the branch is released and everything behaves normally again. Git also prunes on its own schedule: `git gc` removes stale worktree administration older than `gc.worktreePruneExpire` (three months by default), so a forgotten one eventually disappears. `git worktree prune --expire <time>` applies a different cutoff on demand. ## The habit that avoids all of this Use `git worktree remove <path>`. It refuses if the worktree has uncommitted changes or untracked files (`--force` overrides), then deletes both the checkout and its administration in one step. Removing a worktree does not delete the branch it had checked out — that is a separate `git branch -d`. ## The recoverable-loss case The reason `rm -rf` deserves a second thought is not the bookkeeping — that is trivially pruned — but the contents. Anything committed in that worktree is safe in the shared object database and can be found by branch, tag or, if the branch is gone, through the reflog. Anything only *staged or modified* there is gone with the directory: the index lived in the worktree's administrative directory and the file contents lived in the deleted tree. Note also that the HEAD reflog is per-worktree, so the movements of the deleted worktree's HEAD are in its administrative directory — worth reading *before* you prune if you are trying to reconstruct what it was doing. ## Locking and repairing Two neighbouring commands round out the lifecycle: - **`git worktree lock <path>`**, optionally with `--reason "<text>"`, marks a worktree as not prunable. This is for checkouts on removable drives or network mounts that are legitimately absent when unmounted — without the lock, a prune while it is offline would discard its administration and orphan it. `git worktree unlock` reverses it. - **`git worktree repair`** fixes the two-way pointers when they no longer agree — for example after moving a worktree directory with `mv` instead of `git worktree move`, or after moving the main repository so every linked worktree's `.git` file points at the old location. Run it in the repository (optionally passing worktree paths) and it rewrites the pointers to match reality. And **`git worktree move <old> <new>`** is the supported way to relocate a linked worktree in the first place, updating both sides so repair is never needed. ## What good answers include A strong answer names the surviving administrative directory, the two visible symptoms (prunable listing, branch still occupied with an error naming a missing path), the fix (`prune`, with `--dry-run` first), the better habit (`remove`), and at least one of the lifecycle edge cases — `lock` for removable media, `repair` after a manual move. Mentioning that committed work is never at risk, while staged-only work in the deleted directory is, shows you understand where each piece of state lived.