With git 2.9 (June 2016), this (helper =
) will actually work!
See commit 2432137 (26 Feb 2016) by Jeff King (peff
).
(Merged by Junio C Hamano -- gitster
-- in commit 1b68962, 03 Apr 2016)
The
credential.helper
configuration variable is cumulative and there is no good way to override it from the command line.
As a special case, giving an empty string as its value now serves as the signal to clear the values specified in various files.
credential
: let empty credential specs reset helper list
Since the
credential.helper
key is a multi-valued config list, there's no way to "unset" a helper once it's been set. So if your system/etc/gitconfig
sets one, you can never avoid running it, but only add your own helpers on top.
Since an empty value for
credential.helper
is nonsensical (it would just try to run "git-credential-
"), we can assume nobody is using it. Let's define it to reset the helper list, letting you override lower-priority instances which have come before.
Even more convenient: With Git 2.26 (Q1 2020), this override applies even for any value.
See commit 46fd7b3, commit 82eb249, commit 588c70e, commit 732f934, commit 3fa0e04 (20 Feb 2020) by brian m. carlson (``).
(Merged by Junio C Hamano -- gitster
-- in commit 2cbb058, 05 Mar 2020)
credential
: use the last matching username in the configSigned-off-by: brian m. carlson
Everywhere else in the codebase, we use the rule that the last matching configuration option is the one that takes effect.
This is helpful because it allows more specific configuration settings (e.g., per-repo configuration) to override less specific settings (e.g., per-user configuration).
However, in the credential code, we didn't honor this setting, and instead picked the first setting we had, and stuck with it.
This was likely to ensure we picked the value from the URL, which we want to honor over the configuration.
It's possible to do both, though, so let's check if the value is the one we've gotten over our protocol connection, which if present will have come from the URL, and keep it if so.
Otherwise, let's overwrite the value with the latest version we've got from the configuration, so we keep the last configuration value.
Note: user202729 adds in the comments:
If credential helper
A
is set as global and you want to useB
in a local repository (change, not remove the helper), use:git config --local credential.helper '' git config --local --add credential.helper B
The first empty item removes the global setting
A
.Equivalently, set two lines
helper =
andhelper = B
in.git/config
.
What I've tried, and had worked well was:
$ git config --system --unset credential.helper
But in order to that works fine, I had to set git-bash.exe with Administrator rights.
Unfortunately, I think this is a global variable. You should test and see if it works for single repositories.
Good luck
In addition of 'git config credential.helper=
' that I mention above with Git 2.9, you now (Git 2.13.x/Git 2.14, Q3 2017) can disable the credential helper just for one command (and not just for any command in a given repo)
That means git -c credential.helper= clone /url/remote/repo
now works.
"git clone --config var=val
" is a way to populate the
per-repository configuration file of the new repository, but it did not work well when val is an empty string.
This has been fixed.
See commit db4eca1 (02 May 2017) by Jonathan Nieder (artagnon
).
(Merged by Junio C Hamano -- gitster
-- in commit 883247c, 16 May 2017)
clone
: handle empty config values in-c
"
git clone --config
" uses the following incantation to add an item to a config file, instead of replacing an existing value:git_config_set_multivar_gently(key, value, "^$", 0)
As long as no existing value matches the regex
^$
, that works as intended and adds to the config. When a value is empty, though, it replaces the existing value.Noticed while trying to set
credential.helper
during a clone to use a specific helper without inheriting from~/.gitconfig
and/etc/gitconfig
.
That is, I ran:git clone -c credential.helper= \ -c credential.helper=myhelper \ https://example.com/repo
intending to produce the configuration:
[credential] helper = helper = myhelper
Without this patch, the '
helper =
' line is not included and the credential helper from/etc/gitconfig
gets used.
Note that the documentation is now clearer with commit 515360f:
credential doc: make multiple-helper behavior more prominent
Git's configuration system works by reading multiple configuration files in order, from general to specific:
/etc/gitconfig
~/.gitconfig
or ~/.config/git/config
).git/config
)For single-valued configuration items, the latest value wins.
For multi-valued configuration items, values accumulate in that order.For example, this allows setting a credential helper globally in
~/.gitconfig
that git will try to use in all repositories, regardless of whether they additionally provide another helper.
This is usually a nice thing --- e.g. I can install helpers to use my OS keychain and to cache credentials for a short period of time globally.Sometimes people want to be able to override an inherited setting.
For thecredential.helper
setting, this is done by setting the configuration item to empty before giving it a new value.
A config variable that is set to an empty string is not the same as an unset variable. It is not possible to force a variable to be unset in .git/config
when it is already set in ~/.gitconfig
.
Additionally credential.helper
is one of these variables where multiple values are used, and in such cases the values are aggregated from all read config files.
So basically your options seem to be:
either do not use credential.helper
in ~/.gitconfig
; set the store helper only for the repositories where you want it, either in their .git/config
, or in ~/.gitconfig
by specifying the repo URLs, eg.
[credential "https://specific.example.com/repo.git"]
helper = store
or implement your own helper that does nothing for a set of configured repositories and delegates to git credential-store
for the rest.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With