fatal: unable to stat '...': Filename too long from Git for Windows means a file's full path is longer than the classic Windows limit of 260 characters, and Git is not allowed to use long paths in this repository. Turn them on with git config core.longpaths true and run the command again.

The setting can go in the repository, as below, or in your global config with --global if you meet deep paths often. A shorter clone location, such as C:\src instead of a folder deep under your profile, also makes the problem disappear.

The error

> git add .
fatal: unable to stat 'generated-client-sources-for-the-appointment-scheduling-service-version-two-alpha/appointment-scheduling-service-client-navigation-menu-localised-resources.txt': Filename too long

Why it happens

Classic Windows file APIs limit a full path, drive letter included, to MAX_PATH: 260 characters counting the terminating null. Git for Windows only uses the longer form when core.longpaths is true, and on this machine it was not set anywhere. The repository folder in the test was 126 characters long; one folder and one file name inside it brought the full path to 286, so Git could not even read the file's details and stopped with exit code 128. Such paths usually arrive from somewhere else: a repository cloned from Linux or macOS, a node_modules tree, generated client code, or files created from WSL, which is how this one was made.

A quieter variant appears when a folder path is already over the limit: git add . printed warning: could not open directory '...': Filename too long, exited with 0, and left the file out. git status did not list it either, so the file is easy to lose without noticing. The same fix brought it in.

The fix

> git config core.longpaths true
> git add .
> git status --short
A  generated-client-sources-for-the-appointment-scheduling-service-version-two-alpha/appointment-scheduling-service-client-navigation-menu-localised-resources.txt

With core.longpaths on, Git opened the file through the long-path form and the add succeeded. The setting only helps Git: in the same folder, Windows PowerShell 5.1's Get-ChildItem -Recurse still failed with "Could not find item" on that file, so other tools in your build may trip over the same path. If you control the names, shortening the folder structure or cloning closer to the drive root is the more durable fix; core.longpaths is the one to use when you do not.

How it was reproduced

Git for Windows 2.45.2 on Windows 11, run from Windows PowerShell; the Windows LongPathsEnabled registry value was 0 and was not changed. A fresh repository in a scratch folder; a bash script in WSL Ubuntu 24.04 created a folder with an 81-character name and a file with a 77-character name through /mnt/c, which Linux allows. Windows git add . then failed as shown, and the local core.longpaths setting fixed it.

Frequently asked

How do I fix 'Filename too long' in Git on Windows?
Run git config core.longpaths true in the repository, or add --global to set it for every repository, and run the failing command again. Git for Windows then uses long paths for that repository.
Why does git add skip a file with 'could not open directory: Filename too long'?
The folder path is over 260 characters, so Git cannot list it. It prints a warning, exits successfully and leaves the files out. Setting core.longpaths to true lets Git read the folder.
Does core.longpaths fix long paths for other Windows tools?
No. It only changes how Git opens files. In the test, Windows PowerShell 5.1 still failed to find the same file, and other tools may too, so shortening the folder structure is the more durable fix.

More decoded errors in the Fixes category.