Git credential management has always just worked for me on Windows which has been nice. The community initially had wincred or git-credential-winstore for managing Git credentials on Windows but this was replaced with the Git Credential Manager for Windows in 2015. The latter is an official Microsoft project. Both use(d) the Windows Credential Manager for storing Git credentials.
Then I created a second GitHub account to work on a private GitHub repository and it stopped “just working”.
The problem is the credential manager stores credentials by the domain only. It does not include a username or path by default. So the first time you clone a GitHub repo, you will authenticate your Github account via a popup, a personal access token will be created and stored in the credential manager for the github.com domain:
Any future GitHub repo you attempt to access will use these same credentials because the root domain matches. This creates a problem when you attempt to work with a private repo that requires a different account.
>git clone https://robbOtherAccount@github.com/private/acme.svc.git
remote: Repository not found.
fatal: repository ‘https://robbOtherAccount@github.com/private/acme.svc.git/’ not found
The private repo isn’t found because your first account doesn’t have access to the private repo.
For those, with a single GitHub account (which is likely the vast majority of users), this is preferred because you will only have to enter credentials once and those will be used for accessing any future GitHub repo. I completely agree with this decision to make it easy for the majority.
Thankfully, the community has identified this issue and a workaround exists. You can set the credential.useHttpPath global config to change the credential manager’s behavior to store credentials using the full HTTP path instead of the domain only.
>git config –global credential.useHttpPath true
Now each time you access a new repo it will authenticate you for that repo path and store the credentials based on the full HTTP path:
This fixes the scenario above.
The downside to this option is you will now have to set your credentials for each new repo. After the first access the credentials are stored so you will only have to provide them the first time.
A Better Future Solution
I think a better option would be to use the domain along with the username prefix. For example, use “https://robbOtherAccount@github.com” from the repo url “https://robbOtherAccount@github.com/private/acme.svc.git”. This would avoid authentication for every new repo URL and instead would only challenge when you have a new domain/user combination. This would require a code change to the Git Credential Manager for Windows code which I may look at in the future if others agree it would be valuable.
If this post was helpful or you have further questions please leave a comment below to continue the conversation.