[windows] Filename too long in Git for Windows

I'm using Git-1.9.0-preview20140217 for Windows. As I know, this release should fix the issue with too long filenames. But not for me.

Surely I'm doing something wrong: I did git config core.longpaths true and git add . and then git commit. Everything went well. But when I now do a git status, I get a list of files with Filename too long, for example:

node_modules/grunt-contrib-imagemin/node_modules/pngquant-bin/node_modules/bin-wrapper/node_modules/download/node_modules/request/node_modules/form-data/node_modules/combined-stream/node_modules/delayed-stream/test/integration/test-handle-source-errors.js: Filename too long

It is quite simple to reproduce for me: just create a Yeoman web application with the Angular generator ("yo angular") and remove node_modules from the .gitignore file. Then repeat the aforementioned Git commands.

What am I missing here?

This question is related to windows git

The answer is


The better solution is enable the longpath parameter from Git.

git config --system core.longpaths true

But a workaround that works is remove the node_modules folder from Git:

$ git rm -r --cached node_modules
$ vi .gitignore

Add node_modules in a new row inside the .gitignore file. After doing this, push your modifications:

$ git add .gitignore
$ git commit -m "node_modules removed"
$ git push

You could also try to enable long file paths.

If you run Windows 10 Home Edition you could change your Registry to enable long paths.

Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem in regedit and then set LongPathsEnabled to 1.

If you have Windows 10 Pro or Enterprise you could also use Local Group Policies.

Go to Computer Configuration ? Administrative Templates ? System ? Filesystem in gpedit.msc, open Enable Win32 long paths and set it to Enabled.


I had this error too, but in my case the cause was using an outdated version of npm, v1.4.28.

Updating to npm v3 followed by

rm -rf node_modules
npm -i

worked for me. npm issue 2697 has details of the "maximally flat" folder structure included in npm v3 (released 2015-06-25).


If you are working with your encrypted partition, consider moving the folder to an unencrypted partition, for example a /tmp, running git pull, and then moving back.


This might help:

git config core.longpaths true

Basic explanation: This answer suggests not to have such setting applied to the global system (to all projects so avoiding --system or --global tag) configurations. This command only solves the problem by being specific to the current project.

EDIT:

This is an important answer related to the "permission denied" issue for those whom does not granted to change git settings globally.


To be entirely sure that it takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out, it is safer to use it this way:

git clone -c core.longpaths=true <repo-url>

-c key=value

Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out. The key is in the same format as expected by git-config1 (e.g., core.eol=true). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add additional fetch refspecs to the origin remote.

More info


Executing git config --system core.longpaths true thrown an error to me:

"error: could not lock config file C:\Program Files (x86)\Git\mingw32/etc/gitconfig: Permission denied"

Fixed with executing the command at the global level:

git config --global core.longpaths true

In Windows, you can follow these steps which worked for me.

  1. Open your cmd or git bash as an administrator
  1. Give the following command either from cmd or git bash which you ran above as an administrator
git config --system core.longpaths true
  1. This will allow accessing long paths globally

  2. And now you can clone the repository with no issues with long paths


In a windows Machine

Run Command Prompt as administrator then run below command

git config --system core.longpaths true


Move repository to root of your drive (temporary fix)

You can try to temporarily move the local repository (the entire folder) to the root of your drive or as close to the root as possible.

Since the path is smaller at the root of the drive, it sometimes fixes the issues.

On Windows, I'd move this to C:\ or another drive's root.


TortoiseGit (Windows)

For anyone using TortoiseGit for Windows, I did this:

(1) Right-click on the folder containing your project. Select TortoiseGit -> Settings.

(2) On the "Git" tab, click the button to "Edit local .git/config".

(3) In the text file that pops up, under the [core] section, add: longpaths = true

Save and close everything, then re-try your commit. For me, this worked.enter image description here

I hope this minimizes any possible system-wide issues, since we are not editing the global .gitconfig file, but rather just the one for this particular repository.


Create .gitconfig and add

[core]
longpaths = true

You can create the file in a project location (not sure) and also in the global location. In my case the location is C:\Users\{name}\.


git config --global core.longpaths true

The above command worked for me. Using '--system' gave me config file not locked error


You should be able to run the command

git config --system core.longpaths true

or add it to one of your Git configuration files manually to turn this functionality on, once you are on a supported version of Git. It looks like maybe 1.9.0 and after.


Steps to follow (Windows):

  1. Run Git Bash as administrator
  2. Run the following command:
git config --system core.longpaths true

Note: if step 2 does not work or gives any error, you can also try running this command:

git config --global core.longpaths true

Read more about git config here.