1664

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?

Improve this question
6
  • Where do you read that that version should fix the long filenames? Commented Mar 22, 2014 at 9:19
  • Here is the pull request for the patch: github.com/msysgit/git/pull/122 Commented Mar 22, 2014 at 9:31
  • 3
    @v.karbovnichy please read my question carefully. I already ran the command in the top voted answer. But at the time I asked the question, the accepted answer was correct: msys still had this character-limitation. Now that limitation is gone and git config core.longpaths true works like it should. Commented Nov 3, 2017 at 16:33
  • Ok, I agree then Commented Nov 5, 2017 at 18:20
  • 2
    Nowadays there is Linux in Windows in form of WSL2. No restrictions added. Commented May 10, 2021 at 6:26

22 Answers 22

Reset to default
2478

Git has a limit of 4096 characters for a filename, except on Windows when Git is compiled with msys. It uses an older version of the Windows API and there's a limit of 260 characters for a filename.

So as far as I understand this, it's a limitation of msys and not of Git. You can read the details here: https://github.com/msysgit/git/pull/110

You can circumvent this by using another Git client on Windows or set core.longpaths to true as explained in other answers.

git config --system core.longpaths true

NOTE: due to https://github.com/desktop/desktop/issues/8023#issuecomment-515115353, Github Desktop (and potentially other Git GUIs as well) will read the --global config but not the --system config

Git is build as a combination of scripts and compiled code. With the above change some of the scripts might fail. That's the reason for core.longpaths not to be enabled by default.

The windows documentation at https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#enable-long-paths-in-windows-10-version-1607-and-later has some more information:

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled (Type: REG_DWORD)

Appendix - Doing it all from PowerShell - the copy-paste edition

This is a Windows specific issue, hence the solution below should work in most Windows versions, new and old.

Open a PowerShell window/console, and run the following:

  • Setting Registry Value:
# Check LongPathsEnabled settings
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled

# If 0, set it to 1 - This is a System wide configuration
# This will fail if you do not have Admin priveleges
# Changes to CurrentControlSet\Control take effect after a system restart
$MyPSexe = Get-Process -PID $PID | % Path
Start-Process -Verb RunAs $MyPSexe "-c","Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Type DWord -Value 1"
  • Setting git config --system - System wide for all Windows users:
Start-Process -Verb RunAs "git" "config","--system","core.longpaths","true"
  • Alternative - non admin option: Setting git config --global - User's global settings:
& git config "--global" core.longpaths true
Improve this answer
Sign up to request clarification or add additional context in comments.

24 Comments

The limitation to 260 chars in a path is not specific to MSYS, it's a general Windows API imitation. This can be worked around by using Unicode paths, but that has other drawbacks, which is why core.longpaths is not enabled by default. Also note that Git for Windows it not compiled against MSYS. Instead, it's a native Windows application that comes with a stripped-down MSYS environment.
@sschuberth: Are there any drawbacks other than lack of compatibility with programs that do not support long paths?
@JAB Another drawback is that long paths always have to be absolute; relative paths are not supported. For further details please see here.
As of Windows 10, you can edit your registry (or apply a group policy) to remove the Windows API filename length restriction. howtogeek.com/266621/…
Solved for me, but I used --global instead of --system to avoid the need for admin priviliges.
|
1348

You should be able to run the command

git config --system core.longpaths true

from an Administrator command prompt.

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.

Improve this answer

15 Comments

This config option fixed the issue for me, even with msys as mentioned in the accepted answer. (Specifically, version 1.9.4.msysgit.2).
Sourcetree acts a bit weird unless you "also make sure that SourceTree is using the System’s Git and not the embedded one." - Thanks to Matej Drolc for that advice
Here is some background information why this is not enabled by default, and some technical details.
get "could not lock config file C:\Program Files\Git\mingw64/etc/gitconfig" after running command above. But @Yash answer worked for me
@divideByZero running git bash as administrator prevents that error.
|
400

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.

Improve this answer

5 Comments

Folks here have noted that this setting can introduce some unpredictable behavior so it seems that it's preferable to use the above command as a local setting on projects where that require it rather than appending --system which will apply it to all projects
hey, that's just a copypasta of the other highly upvoted answer. might at the very least explain why you prefer removing the --system option..
I didn't have elevated rights and thus this was much easier to do inside the git repository than to ask the IT team to run the global command with elevated rights. Thanks Sagiruddin!
Thank you. I got permission denied and your answer solved my issue
@GrantHumphries what "unpredictable behavior" are you referring to? I found the --global flag was what worked for me, and I want to know what to look out for.
308

On Windows:

  1. Run Git Bash as administrator (right-clicking the app shortcut will show the option to Run 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.

Improve this answer

5 Comments

Thanks for the answer! Using --global command solved the issue for me!
Thanks a lot. The second command actually helped me out; Because it was throwing an error by saying "Permission denied".
git config --global core.longpaths true , this command solved my issue. Thanks!
for me, this worked: git config --global core.longpaths true
Thanks. Step 2 literally helped. [ git config --global core.longpaths true ]
144

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}\.

Improve this answer

9 Comments

You can also do this with the following command: git config --global core.longpaths true
git config --global core.longpaths true worked for me thanks
Using Visual Studio the git bash solutions above did not work for me, but finding the .git/config file for the project and editing as shown above did. Thanks yash.
The above mentioned and verified answers are correct but with the permissions which is granted to the file, it might not be possible to update the file with those commands. This approach is really easy because this is the manual approach and it worked for me really well. You can easily find the .gitconfig file in the following path C:\Users\{username} and simply edit it.
this one is the convenient solution than using the command prompt that requires me permissions
|
71

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

Improve this answer

1 Comment

best option, this avoids setting the system/global config
40

This worked for me

terminal image

Run as terminal as administrator. And run the command below.

git config --system core.longpaths true
Improve this answer

1 Comment

Exact replica of existing answers, years after the fact. Useless image since it's repeated below. Broken grammar. No explanation. (Cherry on top for me, the infamous "worked for me" phrasing.) How has this been upvoted 43 times is beyond me.
39

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
Improve this answer

5 Comments

There's a good reason to keep the node_modules folder checked into git: If you want your software to behave the same after a year of modules potentially vanishing from npm.
@cfstras if some library has a vulnerabily and you don't update periodically, certainly you'll have security problems.
Of course you have to upgrade your dependencies. But only when you want to, and if something were to break, you would want your backup in git...
Is true. I'll edit my anwser. Thank you for you comment.
No need to commit node_modules: the packages.lockfile is here to ensure the version installed by npm installwill always be the same, until you make a npm update
36

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
Improve this answer

2 Comments

The global settings affect only the current user, whereas system settings affect all the users on the machine. If this is your workstation they're effectively the same as you may use only one user.
If you're command line application Ran as Administrator, first command would work!
21
  • Download & Install Git bash from here: https://git-scm.com/download/win
  • Run the git bash gui as administrator and run this command: git config --system core.longpaths true
  • Now clone any repository.
  • If the problem is not fixed try this command: git config --global core.longpaths true
  • If it does not help try restarting the windows.
Improve this answer

2 Comments

What does restarting do exactly
probably just gives ya some hope, as it is usually with computahz ;)
19

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.

Improve this answer

2 Comments

I believe this must be done in combination with the git config, and it's worth noting it doesn't work with Windows Explorer for the reasons mentioned here.
Win32 - I wonder if this can help if the application is 64bit?
19 
git config --global core.longpaths true

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

Improve this answer

1 Comment

for Github Desktop users, this is the only one that works because Github Desktop uses its own Git config.
15

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.

Improve this answer

Comments

8

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

Improve this answer

Comments

8

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.

Improve this answer

1 Comment

This is the only thing that solved my issue. It was that I had too many folders in the path.
5

This error appears whenever some file or folder path in your solution directory is very long. In your solution folder, try following command. It will increase the filepath length in Windows.

git config --global core.longpaths true
Improve this answer

Comments

3

In a windows Machine

Run Command Prompt as administrator then run below command

git config --system core.longpaths true

Improve this answer

Comments

2

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

Improve this answer

Comments

2

For Windows

  1. Enable long path support in Windows by running PowerShell as Administrator and executing:
New-ItemProperty --Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" --Name "LongPathsEnabled" --Value 1 --PropertyType DWORD --Force
  1. Configure Git to handle long paths:
git config --global core.longpaths true

For Linux

  1. Open Git Bash as Administrator.
  2. Set the core.longpaths configuration:
git config --global core.longpaths true

References

Improve this answer

1 Comment

For point 2, in Windows 11 this worked for me (Run git bash/cmd as admin): git config --global core.longpaths true
1

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.

Improve this answer

1 Comment

Could you explain it in detail
1

This is worked for me on Windows:

Start-Process -Verb RunAs "git" "config","--global","core.longpaths","true"
Improve this answer

1 Comment

This runs from Terminal, but worked perfectly for my issue with long file path errors ✅
0

Please follow the steps below to fix "Filename is too long" in Git.

  1. Update to the newest version of git. If you have already upgraded, skip this step.
  2. Navigate to your project folder.
  3. Open the Git Bash and run it as an administrator.
  4. To enable long paths in Git Bash, use "git config --system core.longpaths true"
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.