Can you run git config --list --show-origin to ensure the configuration settings are as expected?

@cagedmantis,
I run this command from different places and it works as expected. I see the configuration setting based on GIT_CONFIG value.
So git command works well but go get does not.

@cagedmantis, Do you need additional info? It will be great feature for ability to work in multiple environments setup when use direnv or similar.

I use direnv to manage environment variables depends on current directory and I think the issue arises when go changes directory under the hood while executes go get -u operation. And GIT_CONFIG value changes (clears). @cagedmantis , Could you confirm that there is directory changing during go get -u operation for some reason?

@valery-barysok Thanks for the additional information. I am not able to reproduce this, even with some direnv experiments. I am going to loop in the maintainers of the go command for good measure.

/cc @bcmills @jayconrod @matloob

@valery-barysok, go get does not change its own working directory, but it does invoke git in a different directory (namely, in the Go module cache).

The go command doesn't know anything about direnv or about the GIT_CONFIG environment variable, so if you're going that route it's on you to ensure that your GIT_CONFIG environment variable is set appropriately for commands executed in the module cache (and, for that matter, in temporary directories).

@valery-barysok, can you confirm that your GIT_CONFIG setting applies to subdirectories of $(go env GOMODCACHE)?

@bcmills, I can confirm that direnv also configured for go env GOMODCACHE in the same way as for dir where i execute go get. As expected it does not work but git clone works in both places. As I understand go get executes git clone and it should work as if i do the same by myself. But it looks like no env variables that provide correct setup of git when executes this command.

@bcmills, I debugged go source code and seems like issue actually happens inside git itself when go executes git ls-remote -q origin while env and git config --list commands before git ls-remote -q origin provide correct values. It is succeed if I put .gitconfig file to user home directory instead of custom place for this operation.

I will continue to investigate.

I resolved the issue by using XDG_CONFIG_HOME env variable instead of GIT_CONFIG.

So GIT_CONFIG is wrong way to provide custom place for git config file because it works with limited list of commands.
There is side effect when you use XDG_CONFIG_HOME because other applications respect this env variable and read/write their setting from this place.