git config --system --edit should use new "super-config" from "C:\ProgramData\Git\config"

[sschuberth]

No description provided.

[linquize]

What a good name super-config!

[sschuberth]

Well, it was @dscho who came up with that name AFAIK.

[dscho]

Can't take credit for that... I call it "Windows-wide config".

[linquize]

as it is Windows-specific config file

[sschuberth]

Not that it matters much, but the branch that was merged in 9c9dc30 was called dscho/super-config which is where I got the name from. Also several variable names contain the string super_config.

[nalla]

That path comes from ETC_GITCONFIG which is defined here. So to me the question arises, what about ETC_GITATTRIBUTES that is defined one line below?

Was the location of ETC_GITATTRIBUTES also discussed with https://github.com/libgit2?

[dscho]

Try this: git config --system -l. It looks for /etc/gitconfig and does not care about C:\ProgramData\Git\config. Now, if it does not do that, why should git config --system --edit?

[kblees]

Reading through libgit2/libgit2#3040 again, I believe the conclusion was to store system-wide configuration in %PROGRAMDATA%/Git/config instead of the installation-specific %PROGRAMFILES%/Git/etc/gitconfig.

So introducing a new "super-config" that cannot be addressed via CLI, and git config --system reading from / writing to the installation-specific config rather than the system-wide config is quite odd IMO.

[sschuberth]

@kblees Exactly my understanding, too. All system related config operations should access %PROGRAMDATA%\Git\config and nothing else in the new Git version.

It looks for /etc/gitconfig and does not care about C:\ProgramData\Git\config.

@dscho I'd say this is a bug then.

[dscho]

Reading through libgit2/libgit2#3040 again, I believe the conclusion was to store system-wide configuration in %PROGRAMDATA%/Git/config instead of the installation-specific %PROGRAMFILES%/Git/etc/gitconfig.

Actually, there are already settings that don't make no sense in that Windows-wide config: the location of the SSL certificates is relative to the location of $prefix/etc/gitconfig. So we actually use both config files.

[kblees]

the location of the SSL certificates is relative to the location of $prefix/etc/gitconfig.

I don't understand that. ETC_GITCONFIG is used only once in git_etc_gitconfig(), which is only used in three places, which don't do any relative path mangling.

[dscho]

Look at line 14 of the gitconfig we install via git-extra. This path is interpreted relative to the $prefix. It would not make sense in %PROGRAMDATA%\Git\config. But it does make sense in $prefix/etc/gitconfig.

[kblees]

Look at line 14 of the gitconfig we install via git-extra. This path is interpreted relative to the $prefix. It would not make sense in %PROGRAMDATA%\Git\config. But it does make sense in $prefix/etc/gitconfig.

Actually I believe a system-wide ca-certificates file makes much more sense than an installation-specific one...e.g. if you add a self-signed certificate of some company-private git server, you don't need to do it for every installation. We'd have to agree on a %PROGRAMDATA% path, of course.

However, I still don't see why the ssl-path issue should hinder us from using %PROGRAMDATA%\Git\config for the system-wide config...these are completely unrelated paths in my understanding. But perhaps I'm just too dumb to grok it.

[dscho]

Actually I believe a system-wide ca-certificates file makes much more sense than an installation-specific one.

So now I should install the CA certificates into %PROGRAMDATA%\Git, too? Unconvinced...

[dscho]

Okay, I made up my mind. The arguments I heard so far do not convince me. If git config --system --edit were to do anything else but to open /etc/gitconfig in an editor, it would be inconsistent behavior, breaking backwards compatibility, and disagreeing with the documentation. Therefore it would be a serious regression to make it so.