Allow specifying a custom gitconfig file

Feature description

Right now GCM adds a [credential] directive to ~/.gitconfig. I'd like to be able to tell GCM which gitconfig file to write the directive to.

Rationale: I manage my dotfiles in a Git repo and don't want to commit sensitive info to that repo. Since the [credential] directive may sometimes contain sensitive info, I'd like to add it to a separate .gitconfig_local file which I include from the main file and don't commit to the dotfiles repo.

the [credential] directive may sometimes contain sensitive info

That should not be the case, ever, if all you use is Git Credential Manager. Granted, other credential helpers sometimes put sensitive information there, but not Git Credential Manager. All that is added to the config is:

an empty value (because credential.helper is actually a multi-valued setting, and the empty value will forget all helpers seen up to that point).
the path to Git Credential Manager.
credential.https://dev.azure.com.useHttpPath is set to true.

Do you consider any of this sensitive information?

Having said this, there is already a way to do what you want, but it is admittedly hard to figure out from Git's documentation. The way to do this is to set the environment variable GIT_CONFIG_GLOBAL. In Git Bash, you would do this:

$ GIT_CONFIG_GLOBAL=~/.gitconfig_local git credential-manager configure

If you use PowerShell or CMD instead, you will set that environment variable in a different manner, of course, but the principle is the very same.

@dscho

@dscho thanks for your reply.

What you said is true regarding the first [credential] directive that's added when running git credential-manager configure. However, I'm referring to the second directive that's added when trying to do e.g. git push to a repo for which GCM is configured. What happens for me is that after I authenticate in the browser tab which gets opened, GCM is adding something similar to the following to my global gitconfig file:

[credential "<redacted>"]
        azureAuthority = https://login.microsoftonline.com/<redacted>
        username = me@example.com

The thing I treat as "secret" is the value of azureAuthority and username. True, they aren't credentials, but azureAuthority is in my case an internal URL which I don't want to accidentally advertise and username is an email address. That's why I was trying to control which gitconfig file is chosen when this directive is added.

Anyway, not a big deal and if there is no easy way to achieve that (or if this feature isn't useful to others) we can just close this issue.

@mjcheetham

What happens for me is that after I authenticate in the browser tab which gets opened, GCM is adding something similar to the following to my global gitconfig file:
[credential "<redacted>"]
        azureAuthority = https://login.microsoftonline.com/<redacted>
        username = me@example.com
The thing I treat as "secret" is the value of azureAuthority and username. True, they aren't credentials, but azureAuthority is in my case an internal URL which I don't want to accidentally advertise and username is an email address. That's why I was trying to control which gitconfig file is chosen when this directive is added.

Ah, I can understand that.

The code that is responsible for this is here.

I am not sure that I can think of an elegant way to accommodate your use case (considering that ~/.gitconfig_local is not used by default, it would require an option to write that .azureAuthority setting to arbitrary files that might not be in Git's config file chain and would therefore open new opportunities for users to become confused). Maybe write that information to the repository config instead? But that would not work in general, e.g. for git clone...

Maybe there would be a good home for this information in the Windows Credential Store? @mjcheetham what are your thoughts on the matter?

Of course, GCM shouldn't be responsible for the way I handle my config files. That's well outside the scope of this project IMO.

But I thought that given the fact that GCM writes something to a gitconfig file, it would make sense to be able to control which file is being written to. Right now we seem to assume that this file is always at ~/.gitconfig, and I'm sure there are some users or use cases for which this assumption is wrong (for whatever reason).

So, I think it's less about my special use case and more about GCM's flexibility (i.e. it's more flexible to be able to control the file path than to have a hardcoded path).

I don't have an opinion about Windows Credential Store, but IMO if we try to solve this the solution should be cross platform (I run GCM on Linux in this case for example).

I also ran into this, and the fact that at the moment it looks like I would have to live with a perpetually dirty gitconfig file is very annoying. In my case I already have a local file included in my global config, which I moved all of the GCM config to, but GCM doesn't seem to recognize that and writes the redundant info to the global file again.

So as a simple solution I think it would be enough to just check whether the relevant options are already set in any included files, which a command like git config get credential.<ORG>.username would do. Then users would be responsible for moving the config themselves if they want to, and GCM won't mess with it afterwards.

The same should also apply to the post-install config, which would address #2010.

In case there are people in this here thread who are interested in addressing this, here is an idea how it could be resolved: Offer a config option to override where GCM writes its information. It could be something like credential.separateGlobalConfigFileForGCM = ~/.gitconfig_local; GCM could be taught to heed that setting when writing to the user's config, while ensuring that ~/.gitconfig contains the necessary include (adding it with the comment # added by GCM).

To find the spot where the code would need to be modified, I followed the code that configures those settings to the GitProcessConfiguration.Set() method. In that method, the levelArg is the thing that contains --global in the call path that you'd want to patch, and it would then need to contain -f {QuoteCmdArg(path)} instead if the config setting indicates a different path.

This would then need to be accompanied with changes to the docs and with at least one test case to verify that it works as expected, of course.

Interestingly the code that updates the authority does first try to see if an authority is already set before writing it. However, it's explicitly using --global, and git config --global does not do include path expansion. I don't entirely know why. But that prevents it from finding pre-existing authorities unless they're in the base GIT_CONFIG_FILE

For me, I'd be perfectly happy if GCM recognized that I've already moved the authority elsewhere, so I'm playing around locally with passing something other than GitConfigurationLeve.Global here. Might be another option if folks are interested.

With include of files in scoped config queries and check-for-value-presence (#2345):

initial credential setup still gets written to the (single) global file (no neat approach to change this)
no more duplication after moving the entry, as the included config data is now taken into account.

@benferse

@benferse can you check if (just) enforcing --include (#2345) is enough to avoid adding additional entries?
I think there are enough checks in place for authority and username.
But I may have misidentified the responsible code (and no way to check with real-world endpoints).

@becm

@becm I did a quick pass just now and got positive results. Using a build of your scope-includes branch and this (abridged) setup:

in ~/.config/git/config:

[include]
  path = ~/.config/git/config.local
[credential]
  azreposCredentialType = oauth
  helper = <etc. etc.>/git-credential-manager
  credentialStore = secretservice

in ~/.config/git/config.local

[credential "some_org"]
  azureAuthority = <some ESTS authority>
  username = me@whatever

I was able to fetch from a repo owned by some_org without getting prompted for credentials, and no new credential directives were added to ~/.config/git/config

@benferse

@benferse with a current GCM and Git version this may already be the observable effect
(reads Config differently).

But for this use case, validating there is no issue when includes are considered should already be sufficient.
To really verify the patch is needed, you'd also have to make sure the Git version is old enough
(pre-2.54, or pre-2.53 of Git-for-Windows)

@becm

@becm That was on Ubuntu 26.04 with git 2.53.0. I also confirmed that I do see the issue with the main branch in your fork

In my opinion just using --local instead of --global in

git-credential-manager/src/shared/Microsoft.AzureRepos/AzureDevOpsAuthorityCache.cs

Line 77 in 986b0d5

config.Set(GitConfigurationLevel.Global, GetAuthorityKey(orgName), authority);

is a very quick fix for this issue which would not really affect anyone, it just moves the discovered authority to the local config.
Sure, that means that every repo once needs to do its own authority discovery, but that also makes every repository independant from other ones.
This is only a quick-fix. I agree that long-term we should look into a configuration setting of some kind that controls the level where this information is stored. I am here only advocating that we can start with making --local the default value in this case.

Moving it to repo scope will lead to invalid state representation for the remote:

shared org is a single credential for different repos (unless the path is part if the identifier)
multiple distinct clones will have no distinction (conflict guaranteed)
remotes (OAUTH) track a single instance per client ID (random client ID per clone required)

Later versions (GCM 2.8, Git 2.54) will behave identical to enforcing --includes in nearly all cases.

fix(config): enable file include in scoped queries (git-ecosystem#2345)

@johananl

Including config files is enabled, support for config cache was extended to older Git versions.
@johananl please re-open if this is not sufficient for you (as hinted in other comments).

@becm

Thanks a lot @becm. On my testing the issue looks resolved: Upon first use GCM inserts a [credential] directive under my .gitconfig, however if I move it manually to an included .gitconfig_local file it's being recognized by GCM and no new directive gets inserted to .gitconfig, which is good enough for me.

Thanks again for addressing this!

Navigation Menu

Repository navigation

Allow specifying a custom gitconfig file #1696

Feature description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow specifying a custom gitconfig file #1696

Description

Feature description

Activity

dscho commented on Aug 27, 2024

johananl commented on Aug 27, 2024

dscho commented on Aug 27, 2024

johananl commented on Aug 29, 2024

janlarres commented on Dec 5, 2025

dscho commented on Dec 5, 2025

benferse commented on Mar 4, 2026

becm commented on May 14, 2026

becm commented on May 16, 2026

benferse commented on May 20, 2026

becm commented on May 20, 2026

benferse commented on May 20, 2026

fredrikhr commented on Jun 22, 2026

becm commented on Jun 22, 2026

becm commented on Sep 16, 2026

johananl commented on Sep 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions