I get "warning: unable to access '/home/some-directory/.config/git/attributes': Permission denied" unless I unset the XDG_CONFIG_HOME variable or set it to `${HOME}/.config` in a wrapper. ${HOME} in this case being /var/lib/portage/home. I'm not sure this is only happens in my system because of all the wrapper scripts I make but portage clearly doesn't refer to the variable at all so I might as well just post a bug for it for future reference. Basically what I think happens is portage ran as EUID 0 switches user context to portage but preserves the value of XDG_CONFIG_HOME causing git to refer to the directory specified in it but it doesn't. So portage so unset it or something. As an aside git also refers to the XDG_CACHE_HOME variable so portage might as well correct that variable when switching even though it may not really be directly affecting porage's runtime just for consistency. The XDG_CACHE_HOME variable is mentioned in Documentation/git-credential-cache.txt. Git version: 2.46.0 Suggestion to reproduce: 1) Make sure `sudo env | grep ^XDG_CONFIG_HOME=` (or without sudo as root) produces an output and that the directory displayed is only accessible to the user. E.g., the directory or the parent directory is set to 0750. 2) Run `sudo emerge --sync` or as root simply run `emerge --sync`. 3) Adding the '-i' option to both sudo commands above might help. If the XDG variables are generated by a PAM module, it can only be reproduced if sudo is also configured to call the PAM module or use another module to give a similar effect. I use pam_xdg for sudo which complies with the XDG Base Directory Specification. Anyway regardless if XDG_CONFIG_HOME is commonly set in root or not, portage, as a user of the git command should properly set the value when switching user contexts. For consistency at least.
Created attachment 907111 [details, diff] Fix that simply excludes the variable
