How to fix Removing worktrees/old-worktree: gitdir file points to non-existent location in Git

First, see what worktrees Git knows about and their status:

# List worktrees with verbose output to see prunable entries
git worktree list --verbose

Output will look like:

/home/user/project              abc1234 [main]
/home/user/project-feature      def5678 [feature]
/home/user/old-worktree                 (error: gitdir file points to non-existent location)

The "(error: ...)" annotation indicates stale worktree data.

Before removing any data, see what Git would prune:

# Dry run - shows what would be removed without doing it
git worktree prune --dry-run --verbose

This outputs messages like:

Removing worktrees/old-worktree: gitdir file points to non-existent location

Review the list to ensure you're not about to remove references to worktrees you still need (e.g., on unmounted drives).

If you're satisfied the listed worktrees are truly gone, prune them:

# Remove stale worktree administrative data
git worktree prune

# Verify they're gone
git worktree list

This removes the subdirectories in .git/worktrees/ that point to non-existent locations. It's a safe operation that only affects metadata, not any actual worktree contents.

If the worktree still exists but was moved, use git worktree repair instead of pruning:

# From the main repository, repair links to a moved worktree
git worktree repair /new/path/to/worktree

# Or run repair from within the moved worktree
cd /new/path/to/worktree
git worktree repair

This updates both the gitdir file in .git/worktrees/<name> and the .git file in the worktree to reflect the new paths.

If the worktree is on removable storage (USB drive, external disk), lock it to prevent accidental pruning:

# Lock the worktree with a reason
git worktree lock /path/to/worktree --reason "On external USB drive"

# Later, when storage is connected, unlock it
git worktree unlock /path/to/worktree

Locked worktrees won't be pruned even if their gitdir points to a non-existent location.

For troubleshooting, examine the worktree metadata directly:

# List all worktree metadata directories
ls -la .git/worktrees/

# Check what path a specific worktree's gitdir points to
cat .git/worktrees/<worktree-name>/gitdir

The gitdir file contains the absolute path to the worktree's .git file. If this path doesn't exist, that's why Git marks it as prunable.

If git worktree repair doesn't work or you need manual control, edit the gitdir file:

# Update the path in the gitdir file
echo "/new/correct/path/to/worktree/.git" > .git/worktrees/<name>/gitdir

# Also update the .git file in the worktree itself
echo "gitdir: /path/to/main/repo/.git/worktrees/<name>" > /new/path/to/worktree/.git

Both sides must be updated to maintain the bidirectional link between the main repository and the worktree.