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