On Wed, Mar 22, 2023 at 04:45:51PM +0000, Coirier, Emmanuel wrote: > I think I found a bug with git credential: this tool doesn't call > the configured credential helper following the configuration rules. > > It calls the system configured credential helper (git config --system) even if another one > is configured (ie: at the global level : git config --global). That's because credential helpers are not a single variable where later entries override earlier ones, but is actually a list of helpers to execute. From "git help credentials": If there are multiple instances of the credential.helper configuration variable, each helper will be tried in turn, and may provide a username, password, or nothing. Once Git has acquired both a username and a password, no more helpers will be tried. > The problem I encountered is that the configured system one (manager-core > in my case) answers a wrong value instead of giving up. The globally > configured (wincred in my case) is then not called at all and my > authentication just fail without any way to manually enter login & pass. If you want to clear any prior entries in the list, you can do that explicitly. From the paragraph right below the one quoted above: If credential.helper is configured to the empty string, this resets the helper list to empty (so you may override a helper set by a lower-priority config file by configuring the empty-string helper, followed by whatever set of helpers you would like). > > What's different between what you expected and what actually happened? > > In this example, the "bla" credential helper is called > even if the wincred should have been the only one to be > called. > > The result is OK since the "bla" credential returned a non > zero return code, then the global credential helper (wincred) was called. Right, this is the correct and documented behavior. You'd just want to reset the list in your local config like: git config --global credential.helper "" git config --global --add credential.helper wincred -Peff
