1

Searching for "git default home directory" will easily net some third party statements that the user folder C:\Users\<account> is said directory.

In practise, this generally holds: Grab a Windows PC without Git, install Git from any source, set a variable in global config => C:\Users\<account>\.gitconfig is created and read by Git.

Now for the second time, I have a system here, where this path spuriously changes to H:\.gitconfig and back - H: being a network drive accessible only via Cisco AnyConnect VPN.

Defining HOME overrides this behaviour, but

I was not able to find official documentation on this matter, although I expect it must exist.

Reasons I was able to exclude:

Might or might not be related:

  • So far I have only seen this interaction with Cisco AnyConnect VPN (not other VPN clients) and a network drive called H: (not other network drive letters).
  • git --version is 2.40.0.windows.1 on the machine currently exhibiting this issue. (I no longer have access to the older one, but I think it had about 2.24.x.windows.y .)
  • All uses of Git have been via cmd.
  • The respective IT departments providing either affected machine claimed to not have any configuration (e.g. group policies) in place, that could explain (aka cause) this behaviour. (And indeed, outside of git, no program seems to automatically put files onto H: - there is only what I put there manually and vestigial files .gitconfig, .lesshst, .viminfo created whenever I dare to use Git at the wrong time.)
  • I have colleagues who claim it does not happen on their machines, even though nominally those should be configured identically.
  • Other people have reported their global .gitconfig to reside on network drives, but none of them noted the location to move around. The well-known/expected/normal way this happens is that USERPROFILE and all point to the network drive and trying to use programs offline simply produces hard errors (there is no automatic fallback to a different path).
Improve this question
2
  • @Destroy666 : Ah, sorry for not reporting back. I have a bit of a problem here: I checked everything in this answer, and while factually correct, none of that seemed to be the reason on my machine. But then I noticed that, despite the administrator's assertion that this was nothing on their end, the behaviour had simply disappeared . Originally I had to define %HOME% to prevent it, but now I no longer need to. So... I have no clue whether that answer was right or not, because I did not catch whatever had to change to fix the issue.
    – Zsar
    Commented Sep 4, 2023 at 12:38
  • @Destroy666 : I'll upvote though, as with the link to the source I could have written a MVE that would emit the read directory, had the issue remained reproducible. Given this is the third machine at the second company where I saw this exact same behaviour, I may eventually be able to come back to it at the next job/project, but it will be a while.
    – Zsar
    Commented Sep 4, 2023 at 12:39

1 Answer 1

Reset to default
1

It is stated how the path is determined e.g. in the official documentation:

By default, git config will read configuration options from multiple files:

$(prefix)/etc/gitconfig
System-wide configuration file.

$XDG_CONFIG_HOME/git/config
~/.gitconfig
User-specific configuration files. When the XDG_CONFIG_HOME environment variable is not set or empty, $HOME/.config/ is used as $XDG_CONFIG_HOME.

These are also called "global" configuration files. If both files exist, both files are read in the order given above.

$GIT_DIR/config
Repository specific configuration file.

$GIT_DIR/config.worktree
This is optional and is only searched when extensions.worktreeConfig is present in $GIT_DIR/config.

You may also provide additional configuration parameters when running any git command by using the -c option. See git for details.

Options will be read from all of these files that are available. If the global or the system-wide configuration files are missing or unreadable they will be ignored. If the repository configuration file is missing or unreadable, git config will exit with a non-zero error code. An error message is produced if the file is unreadable, but not if it is missing.

The files are read in the order given above, with last value found taking precedence over values read earlier. When multiple values are taken then all values of a key from all files will be used.

By default, options are only written to the repository specific configuration file. Note that this also affects options like --replace-all and --unset. git config will only ever change one file at a time.

You can limit which configuration sources are read from or written to by specifying the path of a file with the --file option, or by specifying a configuration scope with --system, --global, --local or --worktree. For more, see OPTIONS above.

So administrator could just use $XDG_CONFIG_HOME env to override it, for instance. Which doesn't seem to be the case here looking at the file name you listed.

GIT_CONFIG_GLOBAL env listed here can be used to override the user locations, too:

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM
Take the configuration from the given files instead from global or system-level configuration files. If GIT_CONFIG_SYSTEM is set, the system config file defined at build time (usually /etc/gitconfig) will not be read. Likewise, if GIT_CONFIG_GLOBAL is set, neither $HOME/.gitconfig nor $XDG_CONFIG_HOME/git/config will be read. Can be set to /dev/null to skip reading configuration files of the respective level.

It could also even be a customized git build that modifies this file and maybe some others to read the config in a different way.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .