-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error "No credential store has been selected" when using multiple credential helpers #1283
Comments
It would be interesting to understand any differences in behaviour between typical GCM configuration with internal credential store:
and using GCM as one of multiple Git credential helpers
|
At least for the macOS Keychain, there are some differences in the actual keychain entry that is used. GCM uses The other is the identity of the application that is actually reading/writing to the keychain is different. macOS Keychain's ACLs record the specific executable identity that can access those entries: Finally, we preface our credentials with an optional namespace that is user configurable.. defaulting to |
One thing we could consider is adding a |
Add a null/no-op credential store option that, as the name suggests, does nothing. This can be useful if the user wants to use another credential helper, configured in-front of GCM via Git, to store credentials. Example config: ```ini [credential] credentialStore = none helper = /bin/my-awesome-helper helper = /usr/local/bin/git-credential-manager ``` In this example, the `my-awesome-helper` will be consulted first to retrieve existing credentials before GCM, and will be asked to store any credentials generated by GCM. Fixes #1283
Git supports multiple credential helpers configured in sequence. I tried the following Git config to use a custom storage helper followed by GCM:
But GCM gave me error:
This refers to the choice of GCM's internal credential store. This error makes sense when GCM is the only Git credential helper, but is superfluous when multiple credential helpers are configured.
Workaround: effectively disable GCM's internal credential store by telling it to cache with timeout zero.
The text was updated successfully, but these errors were encountered: