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

GitBEGINNERLOWUpdated Dec 6, 2025· 211 views

This message appears when Git detects worktree administrative data pointing to directories that no longer exist. Learn how to prune stale worktrees or repair broken references.

Quick fix

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

# List worktrees with verbose output to see prunable entries
git worktree list --verbose
  1. Check current worktree status
  2. Preview what will be pruned
  3. Prune stale worktree references
  4. Repair worktree links instead of pruning
git — error
# List worktrees with verbose output to see prunable entries
git worktree list --verbose
Removing worktrees/old-worktree: gitdir file points to non-existent location

What this error means

When you see "Removing worktrees/<name>: gitdir file points to non-existent location", Git is telling you that a worktree's metadata in `.git/worktrees/` contains a `gitdir` file pointing to a directory that no longer exists on your filesystem. Git worktrees allow you to have multiple working directories attached to the same repository. Each worktree has a corresponding subdirectory in `.git/worktrees/` that tracks its location via a `gitdir` file. This file contains the absolute path back to the worktree's `.git` file. When that referenced location is missing (because the worktree was manually deleted, moved, or is on unmounted storage), Git flags it as "prunable." This message typically appears during `git worktree list --verbose` or `git worktree prune` operations. It's informational, not an error - Git is identifying stale references that can be safely cleaned up.

Typical symptoms

  • Running 'git worktree list --verbose' shows 'prunable: gitdir file points to non-existent location'
  • Git operations mention 'Removing worktrees/<name>: gitdir file points to non-existent location'
  • A worktree directory was manually deleted but Git still tracks its metadata
  • Worktree data persists in .git/worktrees/ for directories that no longer exist
  • Git garbage collection outputs messages about stale worktrees

Common causes

  1. The worktree directory was manually deleted (rm -rf) instead of using 'git worktree remove'
  2. The worktree was on removable storage that is currently unmounted
  3. The worktree directory was moved or renamed without updating Git
  4. A backup restoration or disk operation removed the worktree directory
  5. The worktree was on a network share that is no longer accessible
  6. System crash or power loss occurred before Git could clean up worktree metadata

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

1Check current worktree status

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

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

Output will look like:

bash
/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.

2Preview what will be pruned

Before removing any data, see what Git would prune:

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

This outputs messages like:

bash
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).

3Prune stale worktree references

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

bash
# 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.

4Repair worktree links instead of pruning

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

bash
# 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.

5Lock worktrees on removable storage

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

bash
# 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.

6Manually inspect worktree metadata

For troubleshooting, examine the worktree metadata directly:

bash
# 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.

7Manually fix gitdir file (if needed)

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

bash
# 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.

Advanced notes

### How Worktree Tracking Works

Each linked worktree has a corresponding subdirectory in .git/worktrees/. This directory contains:
- gitdir: Absolute path back to the worktree's .git file
- HEAD: The worktree's current HEAD reference
- index: The worktree's staging area
- locked (optional): Present if the worktree is locked, contains the lock reason

The worktree directory itself contains a .git file (not directory) with content like:

bash
gitdir: /path/to/main/repo/.git/worktrees/worktree-name

This bidirectional linking allows Git to find the main repository from the worktree and vice versa.

### Automatic Pruning During Garbage Collection

Git automatically prunes stale worktree data during garbage collection based on gc.worktreePruneExpire:

bash
# Check current setting (default: 3 months)
git config gc.worktreePruneExpire

# Set a different expiration (e.g., never expire)
git config gc.worktreePruneExpire never

# Or expire immediately on gc
git config gc.worktreePruneExpire now

### Worktree Prune vs. Worktree Remove

- git worktree prune: Removes administrative data for worktrees that no longer exist on disk
- git worktree remove <path>: Removes both the worktree directory and its administrative data

Always prefer git worktree remove when intentionally deleting a worktree. Use prune only for cleanup after accidental deletions or system failures.

### Relative Paths in Worktrees (Git 2.42+)

Git 2.42 added --relative-paths for worktree operations:

bash
# Create worktree with relative paths (portable across machines)
git worktree add --relative-paths ../feature-worktree feature

# Convert existing worktree to relative paths
git worktree repair --relative-paths

Relative paths make worktrees more portable but can break if either directory is moved independently.

Frequently asked questions

What does "Removing worktrees/old-worktree: gitdir file points to non-existent lo" mean?
git/worktrees/ contains a gitdir file pointing to a directory that no longer exists on your filesystem. Git worktrees allow you to have multiple working directories attached to the same repository. git/worktrees/ that tracks its location via a gitdir file.
How do I fix "Removing worktrees/old-worktree: gitdir file points to non-existent lo"?
This message appears when Git detects worktree administrative data pointing to directories that no longer exist. Learn how to prune stale worktrees or repair broken references.
What causes "Removing worktrees/old-worktree: gitdir file points to non-existent lo"?
The worktree directory was manually deleted (rm -rf) instead of using 'git worktree remove' The worktree was on removable storage that is currently unmounted The worktree directory was moved or renamed without updating Git
Is the "Removing worktrees/old-worktree: gitdir file points to non-existent lo" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading