Fix 'fatal: filename too long' in Git on Windows

Overview

On Windows, you can hit fatal: filename too long when Git encounters paths exceeding the traditional MAX_PATH limit (260 characters). Modern Git for Windows can bypass this limit if you:

• Enable Git's core.longpaths
• Enable Windows long paths policy (Windows 10/11, Server 2016+)

This guide shows quick fixes, a minimal repro, alternatives if policy changes aren’t possible, pitfalls, and performance notes.

Quickstart (do this first)

1. Update Git for Windows to a recent version (2.10+ supports long paths; newer is better).

2. Enable Git’s long path support:

# In Git Bash or cmd
git config --global core.longpaths true

1. Enable Windows long paths (requires Administrator):

# Run PowerShell as Administrator
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
  -Name LongPathsEnabled -Value 1 -PropertyType DWord -Force | Out-Null

1. Open a new terminal and retry your Git command (clone/checkout/pull). If a checkout failed earlier, try:

git reset --hard

If the working tree wasn’t created, reclone after the change.

Minimal working example

The snippet below reproduces the issue by creating a very deep path in a test repo. First try without the fix, then apply the quickstart and rerun.

# Git Bash
mkdir lp-demo && cd lp-demo

git init
p=long
for i in {1..40}; do p="$p/segment$i"; done
mkdir -p "$p"
echo "ok" > "$p/file.txt"

git add -A
# On default Windows settings, this may emit: "fatal: filename too long"
# After enabling core.longpaths + Windows long paths, it should succeed.

git commit -m "Add deep file"

Alternatively, simulate the failure during checkout by pushing this commit to a remote and recloning before/after enabling long paths.

Step-by-step fixes

1. Verify Git version

git --version

• If older than 2.10, upgrade Git for Windows.

1. Enable Git long paths

git config --global core.longpaths true

• Use --system instead of --global if you want it for all users (requires Administrator):

git config --system core.longpaths true

1. Enable Windows long paths policy (Admin)

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
  -Name LongPathsEnabled -Value 1 -PropertyType DWord -Force | Out-Null

• Sign out/in or open a new shell for the setting to take effect.
• On managed machines, this might be controlled by Group Policy.

1. Retry your operation

• For a repo that partially checked out, try:

git clean -ffd
git reset --hard

• If clone failed early, reclone after enabling the settings.

Practical workarounds (if policy changes are not possible)

• Move the repo closer to the drive root

  • Example: clone to C:\src\myrepo instead of a deeply nested user folder.

• Use sparse-checkout to avoid very deep paths

git clone --no-checkout <REMOTE-URL> myrepo
cd myrepo
git sparse-checkout init --cone
git sparse-checkout set app service docs
# Now checkout fewer directories, often avoiding long paths

• Rename or flatten directory structures where feasible

  • Shorten long folder names in your project or reduce nesting.

• Use WSL for development

  • Cloning inside the WSL Linux filesystem avoids Windows path limits (use the Linux path, not /mnt/c). Avoid cross-OS editing.

Which fix should I choose?

Pitfalls and gotchas

• Admin rights required: Enabling Windows long paths modifies HKLM and may need Group Policy changes in enterprise environments.
• Git only change is not always enough: core.longpaths removes Git’s internal check, but Windows must allow long paths for OS calls to succeed.
• Tools mismatch: Some editors, archivers, or build tools may still not support long paths even after enabling them.
• Network shares: Some SMB shares or backup tools may impose their own limits.
• Very old Windows: Long paths require Windows 10/Server 2016 or newer. On older versions, use workarounds.

Performance notes

• Git performance impact is minimal after enabling long paths. The code paths primarily switch to wide-character APIs.
• Keeping your repository path short (e.g., C:\src) reduces path length risk and can slightly improve file I/O during builds.
• Sparse-checkout can improve performance by reducing working tree size, independent of path length.
• File watchers: Consider enabling Git’s FSMonitor integration to speed up status operations; path length has little effect here.

FAQ

• Do I need both core.longpaths and Windows long paths enabled?

  • Recommended. Git’s flag removes internal checks; Windows’ policy allows long path API calls to succeed.

• Do I need to reclone my repository?

  • Not always. Try git clean -ffd and git reset --hard. If initial clone failed, reclone after enabling the settings.

• Will this affect non-Git tools?

  • Yes, the Windows policy enables long paths system-wide. Some tools may still not handle long paths correctly.

• Is this setting portable across platforms?

  • core.longpaths is Windows-specific. On Linux/macOS, long paths typically aren’t restricted the same way.

• Can I fix this without admin rights?

  • You can set core.longpaths and move your repo closer to the drive root or use sparse-checkout. Full removal of the limit generally requires the Windows policy change.