Git: System configuration cannot be read/written via "git config --system"

[kriegaex]

The problems in #315 are caused by the fact that Git 2.5.0 itself cannot read or write its own system configuration:

$ git config --list --system
fatal: unable to read config file 'C:\Program Files\Git\mingw64/etc/gitconfig': No such file or directory

$ git config --system user.name "Alexander Kriegisch"
error: could not lock config file C:\Program Files\Git\mingw64/etc/gitconfig: Permission denied

This is because Git for Windows has decided to put the system config under _/c/ProgramData/Git/config_ instead of the expected and documented location _/etc/gitconfig_. This is a regression bug because it breaks compatibility not only to Git for Windows 1.9.5 but also to current Git versions on other platforms. External Git clients such as JGit expect to find the system config there and we cannot expect all clients and IDEs to be changed just because Git 2.5.0 for Windows decided to change the location.

My suggestion is to either change the location back to _/etc/gitconfig_ (optimal case) or at least to create something like a Windows hard link from the expected to the changed location. The latter option is suboptimal though, because it works on NTFS but not e.g. on FAT filesystems which have no notion of hard links, e.g. imagin a portable Git installation on a USB stick.

Here is a proof of concept which fixes the Git commands from above as well as third-party tools such as JGit:

ln -f /c/ProgramData/Git/config /etc/gitconfig

Test JGit (formerly it returned an empty result):

$ org.eclipse.jgit.pgm/target/jgit config --system --list | grep 'autocrlf'
core.autocrlf=input

Test native Git 2.5.0:

$ git config --system --list | grep 'autocrlf'
core.autocrlf=input

[anb0s]

We have also different clients using "Git for Windows" and JGit (Eclipse EGit, Gerrit) and searching for solution. The migration from 1.9.5 to 2.5.0 is blocked by this issues (and other we are investigating).

I wold also suggest like kriegaex did: "My suggestion is to either change the location back to /etc/gitconfig".

May i ask for the reason to change the location of the file?

[dra27]

Does git config --system user.name "Alexander Kriegisch" work if you run the command from an _elevated_ command prompt - it should write to C:\Program Files\Git\mingw64\etc\gitconfig and git config --system --list should then work?

I would agree that the output from git config --system --list is a bug, but I don't agree with your solution. Installation of configuration data to C:\ProgramData\Git\config is entirely correct, and doing anything which essentially causes the configuration to be being written in C:\Program Files is _very_ bad. This is Git _for Windows_, not Git _for MSYS_ so referring to the configuration as /etc/gitconfig makes no sense.

The documented location for the system configuration is also not /etc/gitconfig, it's $(prefix)/etc/gitconfig, so a tool which is hard-coded to /etc/gitconfig is what needs fixing (ideally to use the git config command correctly). It is also possible to configure Git with an entirely different ETC_GITCONFIG. I would argue JGit needs to be configured to pick up Git-for-Windows's system configuration file, not Git-for-Windows adapted to place it where JGit naively expects, IMO.

As a compatibility fix, a symbolic link would be good for backwards compatibility (they can be created in MSYS2, subject to the usual constraints, by setting the MSYS environment variable to winsymlinks:nativestrict) - but as with hardlinks, that limits the fix to installations on NTFS, and only Windows Vista+.

[YueLinHo]

May i ask for the reason to change the location of the file?

Perhaps you could find some reasons from this long discussion.

[dscho]

May i ask for the reason to change the location of the file?

Perhaps you could find some reasons from this long discussion.

And also in the release notes.

[dscho]

The idea of a system config being part of the system files is by design. Frequently those system files are protected by the administrator against modification by non-administrators. This feature works exactly as intended.

[dra27]

Sorry, my mistake - I hadn't realised that C:\ProgramData\Git\config was the "super-config" rather than the system config (perhaps a docs improvement for mingw64/share/doc/git-doc/git-config.html#FILES?)
However, shouldn't the installer put an empty file in C:\Program Files\Git\mingw64\etc\gitconfig so that git config --system --list doesn't return an error message by default?
It does feel "odd" that there's no switch so that you can say, for example, git config --super --list and see _just_ the contents of the values in C:\ProgramData\Git\config but it sounds like that's already been considered/decided-against?

[kriegaex]

The fact remains that after a correct Git installation there is an error message on the console and Git cannot find its own system config file. So why do you close the ticket as "wontfix", blaming external tools for searching for the file in a location documented in its very user manual for the _config_ command? To me this is unbelievable.

Edit: Creating a symlink or hardlink - whatever works best according to your experience - during the installation process for backward compatibility is still a good idea because no matter if the system config is under _[GIT_BASE]/mingw64/etc/gitconfig_ or _[GIT_BASE]/etc/gitconfig_, the fact remains that Git for Windows keeps its own system config in _C:\Program Files\Git_, not in _C:\ProgramData_ according to your own statements here.

Edit 2: I forgot to mention that in if order to modify Git's system settings an elevated prompt is needed, this is fine with me. I apologise for not knowing this or not having read it in any manual. I only searched for it in the manpage for git config.

[peterdrowland]

So I'm relatively new to all this computer science business, but I just installed git bash and I'm having the same problem with git/windows not being able to find its own config file. I tried the link as kriegaex recommended, and it seemed to work, but when I restarted the program my progress was lost.

so I guess my real question is this: for a course I'm taking it wanted me to assign my user name/email to the config file, but how important is that? I've spent more time trying to do that than I've spent on the rest of the course so far. will not having my name/email linked impact me in any meaningful way? what am I losing by not manipulating this ever elusive config file?

[PhilipOakley]

Hi Peter,
I guess you are using a computer that has been provided and not a personal computer - would that be right? (It is normally worth starting a new issue so that these basic points can be guided by the template).

It is worth having your own name in a config file. If you can't eneter it into the --global config file, then put it in the local config file (i.e. specific to the repository you are working on. - I have to do that for home vs work repositories). If you don't complete the email etc details then you end up being known as (euphemistically) "joe.nobody". It won't take long before you do feel that, yes, it is worth putting your own name on your work, even if the first week or so is just doing rote excercises that leave no lasting trace beyond the learning.

use the git config -h to check the usage. note the --global and --local, and --show-origin options. Enjoy.

[kriegaex]

I remembered this issue again due to recent activity on the related issue MRELEASE-899.

I could reproduce this problem with the latest Git version 2.29.2.windows.3. Because I was curious, I upgraded

• Maven Release Plugin from 2.5.2 to 3.0.0-M1,
• Maven SCM Provider JGit from 1.9.4 to 1.11.2,
• JGit from 3.7.1.201504261725-r to 5.10.0.202012080955-r.

See also the diff in my sample project https://github.com/kriegaex/git-maven-problem/compare/problem...master for exact details.

These upgrades fixed the problem. I also tried with JGit standalone again like I described in the initial post via

org.eclipse.jgit.pgm/target/jgit config --system --list

and this time the output was also as expected. That means the issue is fixed in JGit. I did not check since which exact version this was fixed, but with the configuration you see in my sample repo it definitely works in my case and with my Git configuration on Windows 10. Maybe this helps someone else too.

BTW, when checking out tag problem with the older JGit and Maven Release versions, the error is reproducible again.