Consider falling back to %APPDATA%\Git\config if XDG_CONFIG_HOME is unset

[dscho]

This setting would make a lot of sense for people with roaming profiles. Of course it would be Windows-only.

Thoughts?

[whoisj]

👍 I love this idea.

With new versions of Windows (Win8+) the config would end up in the AppData (roaming) folder and would be replicated between machines using the same Live account logon (assuming one was used). This would reduce the friction of setting up Git on new systems as well as maintaining a list of useful aliases, etc. across a series of machines (much like how Chrome ships your passwords around, but less horrifying that storing my secrets in the cloud).

[YueLinHo]

/cc @csware @ch3cooli

[dscho]

/cc @ethomson

[jberezanski]

Excellent idea. The config would also replicate between machines in enterprise environments with roaming profiles enabled. A definite win for the user.
Plus, it would make Git a bit more well-behaved Windows citizen (respecting guidelines for configuration data placement).

[ethomson]

I like where this is going - can we enumerate (again) the search paths? I'm sorry to confess that I'm starting to find the list a little confusing.

[dscho]

@ethomson the search order is (highest priority first):

1. .git/config
2. $HOME/.gitconfig
3. $XDG_CONFIG_HOME/git/config (falling back to $HOME/.config/git/config if XDG_CONFIG_HOME is not set)
4. $prefix/etc/gitconfig (i.e. with Git for Windows 2.x, /mingw64/etc/gitconfig or /mingw32/etc/gitconfig, depending on your architecture)
5. On Windows only: %PROGRAMDATA%\Git\config

Basically, the proposal of this ticket (which is really @whoisj's proposal, I should not take credit for it) is to modify the XDG_CONFIG_HOME logic. Probably the way to go is to fall back to %APPDATA%\Git\config if that exists, and only then to $HOME/.config/git/config. Maybe a patch says it best:

diff --git a/path.c b/path.c
index 10f4cbf..15e56f2 100644
--- a/path.c
+++ b/path.c
@@ -906,7 +906,8 @@ int is_ntfs_dotgit(const char *name)

 char *xdg_config_home(const char *filename)
 {
-   const char *home, *config_home;
+   const char *home, *config_home, *appdata;
+   char *home_config = NULL;

    assert(filename);
    config_home = getenv("XDG_CONFIG_HOME");
@@ -915,6 +916,22 @@ char *xdg_config_home(const char *filename)

    home = getenv("HOME");
    if (home)
-       return mkpathdup("%s/.config/git/%s", home, filename);
-   return NULL;
+       home_config = mkpathdup("%s/.config/git/%s", home, filename);
+
+#ifdef WIN32
+   appdata = getenv("APPDATA");
+   if (appdata) {
+       char *buf = mkpathdup("%s/Git/%s", appdata, filename);
+       if (file_exists(buf)) {
+           if (home_config && file_exists(home_config))
+               warning("'%s' was ignored because '%s' exists",
+                   home_config, buf);
+           free(home_config);
+           return buf;
+       }
+       free(buf);
+   }
+#endif
+
+   return home_config;
 }

(Of course we would need to clean this up so that platform-dependent code lives in compat/ but that would just clutter the idea...)

[dscho]

I do not feel that this idea has enough traction to keep this ticket open much longer. Holler if you disagree. Or even better: open a Pull Request implementing the desired functionality.

[ariellourenco]

Hi there,

I am wondering whether it does not make sense to reopen this issue as this days a lot of people dislike having a lot of file in their home? This was a very good idea back in the day, unfortunately, it hadn't moved forward.

Even some very prominent *nix-first programs, such as VIM, are towards this direction.

[dscho]

I am wondering whether it does not make sense to reopen this issue

An alternative to this would be to implement the PR I suggested, which would most likely increase the chances of getting that traction again that we were missing before.

[ariellourenco]

Hi @dscho, I can try to implement your PR for sure. I will start working on this over the weekend, is there any guidelines for contribute to the project?

[dscho]

Hi @dscho, I can try to implement your PR for sure. I will start working on this over the weekend, is there any guidelines for contribute to the project?

I usually point people to https://github.com/git-for-windows/git/blob/main/CONTRIBUTING.md and to https://git-scm.com/docs/SubmittingPatches. That's quite a lot of documentation right there, so I'd encourage you to read the former (it's a bit of a quicker read), work on the patch to make it do what you need, then open a PR and then we can iterate from there.