Trying to set file name length limit with git - Permission denied

Question

I am trying to clone a GitHub repository containing files with long path names, and I am trying to get around Git's file length restriction using the command

git config --system core.longpaths true

However, I am getting the error messages:

error: could not lock config file C:\Program Files\Git\mingw64/etc/gitconfig: Permission denied
error: could not lock config file C:\Program Files\Git\mingw64/etc/gitconfig: Invalid argument

This seems strange, as the command is trying to change a file in Program Files, not in C:\Users\username where it should be. Furthermore, when I checked C:\Users\username for a .gitconfig file, I was unable to find one. Does anyone know what is going on?

Answer 1

1. open cmd shell

as administrator

2. go in program files git
3. run git-bash and change it

git config --system core.longpaths true

ps check my gitst about cloning ;) https://gist.github.com/obar1/45175bf22e5c56967b448a666631b21c

Answer 2

You want git config --global.

This seems strange, as the command is trying to change a file in Program Files, not in C:\Users\username where it should be.

That is expected behavior. Since you ran git config --system it will look for a system-wide config file. From the git-config docs...

--system

For writing options: write to system-wide $(prefix)/etc/gitconfig rather than the repository .git/config.

What you probably want is git config --global to write to YOUR global git config file in your user directory. This is in contrast to git config --local which is for writing to the current repository's config file in .git/config.

--global

For writing options: write to global ~/.gitconfig file rather than the repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the ~/.gitconfig file doesn't.

I expect msysgit didn't change the behavior of git config --system, so it's naively mashing together a Windows style prefix C:\Program Files\Git\mingw64 with a Unix style /etc/gitconfig and getting a nonsense path with mixed delimiters.

Consider letting them know about this behavior and suggest it be given a better error message.