How to fix fatal: no such path 'file.txt' in HEAD in Git

GitBEGINNERLOWUpdated Dec 6, 2025· 157 views

This error occurs when git blame cannot find the specified file in the HEAD commit. Common causes include case sensitivity mismatches, renamed files, files not yet committed, or symbolic links.

Quick fix

Fixes fatal: no such path 'file.txt' in HEAD

git ls-files path/to/file.txt
  1. Verify the file exists in Git's index
  2. Check for case sensitivity issues
  3. Handle uncommitted or new files
  4. Handle renamed or moved files
git — error
git ls-files path/to/file.txt
fatal: no such path 'file.txt' in HEAD

What this error means

The `git blame` command annotates each line of a file with information about the last commit that modified it—who made the change, when, and in what commit. When you see "fatal: no such path 'file.txt' in HEAD", Git is telling you that the file path you specified doesn't exist in the HEAD commit (your current branch's latest commit). This error is particularly common on Windows and macOS where the filesystem is case-insensitive, but Git's internal storage remains case-sensitive. For example, if you renamed a folder from "Foo" to "foo", Git may track both as separate entities, causing confusion when trying to blame files. The error can also occur when the file exists in your working directory but hasn't been committed yet, when the file has been renamed or moved, when dealing with symbolic links, or when working with git submodules where the path refers to content inside the submodule rather than the main repository.

Typical symptoms

  • git blame command fails with 'fatal: no such path' error
  • File exists in working directory but blame still fails
  • IDE annotations (IntelliJ, VS Code, Android Studio) fail to show git blame
  • Vim Fugitive :Gblame command reports file not found
  • CI/CD scripts that use git blame fail unexpectedly

Common causes

  1. File path case sensitivity mismatch (most common on Windows/macOS)
  2. File exists locally but has not been committed to the repository yet
  3. File was recently renamed or moved and the old path is being used
  4. The path points to a symbolic link instead of the actual file
  5. The path is inside a git submodule
  6. File is listed in .gitignore and was never tracked

How to fix "fatal: no such path 'file.txt' in HEAD"

1Verify the file exists in Git's index

First, check if Git knows about the file using git ls-files:

bash
git ls-files path/to/file.txt

If this returns nothing, the file isn't tracked by Git. If it returns a different path (different case), you have a case sensitivity issue.

To see all files in a directory:

bash
git ls-files path/to/directory/
2Check for case sensitivity issues

On Windows and macOS, file systems are often case-insensitive, but Git is always case-sensitive. Compare what Git sees versus what your filesystem shows:

bash
# What Git tracks
git ls-files | grep -i filename

# What the filesystem shows
ls -la path/to/

If the cases don't match, rename the file in Git to match:

bash
# Use a two-step rename to change case
git mv Folder/File.txt Folder/file-temp.txt
git mv Folder/file-temp.txt Folder/file.txt
git commit -m "Fix file case sensitivity"
3Handle uncommitted or new files

If the file exists but hasn't been committed, you need to commit it first before you can blame it:

bash
# Check file status
git status path/to/file.txt

# If it shows as untracked or modified, add and commit
git add path/to/file.txt
git commit -m "Add file for tracking"

# Now blame will work
git blame path/to/file.txt

For files that exist in a different commit but not in HEAD, specify the commit:

bash
git blame <commit-hash> -- path/to/file.txt
4Handle renamed or moved files

If the file was renamed, use the --follow flag to track it across renames:

bash
git blame --follow path/to/newname.txt

If you need to blame the old filename as it existed in a previous commit:

bash
git blame HEAD~5 -- path/to/oldname.txt

Or use the --contents flag to blame old filename with new file's contents:

bash
git blame --contents newname.txt -- oldname.txt
5Check for symbolic links

Verify if the file is actually a symbolic link:

bash
ls -la path/to/file.txt

If you see -> pointing to another location, it's a symlink. Try blaming the actual file instead:

bash
# Find where the symlink points
readlink -f path/to/file.txt

# Blame the actual file
git blame /actual/path/to/file.txt
6Handle submodule paths

If the path is inside a git submodule, git ls-files in the parent repo will only show the submodule directory, not its contents.

Navigate into the submodule and run blame there:

bash
cd path/to/submodule
git blame file.txt

# Or use git -C to specify the directory
git -C path/to/submodule blame file.txt
7Explicitly specify HEAD for working copy issues

Sometimes the error occurs due to line ending differences (CRLF vs LF) between your working copy and the repository. Explicitly specifying HEAD can bypass this:

bash
git blame HEAD -- path/to/file.txt

This blames the version in HEAD rather than the working copy, avoiding line ending comparison issues.

8Verify repository integrity

If none of the above solutions work, your repository might have integrity issues:

bash
# Check repository consistency
git fsck

# Clean up and optimize the repository
git gc

# Re-fetch objects if needed
git fetch --all

If errors are found, you may need to re-clone the repository.

Advanced notes

### IDE and Editor Integration Issues

Many IDEs (IntelliJ, VS Code, Android Studio) and editors (Vim with Fugitive) use git blame internally for annotations. When this error appears in these tools:

1. IntelliJ/Android Studio: Go to VCS > Git > Annotate, and ensure the file is saved and committed
2. VS Code: GitLens extension may fail silently; check the Output panel for the Git channel
3. Vim Fugitive: :Gblame requires the file to be tracked; use :Git status first

### Working with Bare Repositories

In a bare repository (no working tree), git blame -- path will fail because there's no working copy to compare against. Always specify a revision:

bash
git blame HEAD -- path/to/file.txt
# or
git blame main -- path/to/file.txt

### Git Configuration for Case Sensitivity

On case-insensitive filesystems, you can configure Git to be more careful:

bash
git config core.ignorecase false

This makes Git stricter about case, but may cause issues if your repository already has case conflicts.

### Debugging Path Issues

To see exactly what paths Git knows about:

bash
# List all tracked files
git ls-tree -r HEAD --name-only

# Search for a file pattern
git ls-tree -r HEAD --name-only | grep -i "searchterm"

Frequently asked questions

What does "fatal: no such path 'file.txt' in HEAD" mean?
The git blame command annotates each line of a file with information about the last commit that modified it—who made the change, when, and in what commit. txt' in HEAD", Git is telling you that the file path you specified doesn't exist in the HEAD commit (your current branch's latest commit). This error is particularly common on Windows and macOS where the filesystem is case-insensitive, but Git's internal storage remains case-sensitive.
How do I fix "fatal: no such path 'file.txt' in HEAD"?
This error occurs when git blame cannot find the specified file in the HEAD commit. Common causes include case sensitivity mismatches, renamed files, files not yet committed, or symbolic links.
What causes "fatal: no such path 'file.txt' in HEAD"?
File path case sensitivity mismatch (most common on Windows/macOS) File exists locally but has not been committed to the repository yet File was recently renamed or moved and the old path is being used
Is the "fatal: no such path 'file.txt' in HEAD" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading