Open calle2010 opened 1 month ago
For the record, if I set
git config --global "credential.https://dev.azure.com.useHttpPath" true
in WSL, I see no errors. But then the fix in #1522 is also not needed.
Due to the way Git calls credential helpers, and the way Azure DevOps authentication works GCM needs to know the account/org name to authenticate. Without credential.useHttpPath
set to true
, GCM doesn't know the org to authenticate against - it only gets "dev.azure.com" from Git which isn't enough information.
As you have found there appears to be a bug in storing..
Thank you for looking into this. Please note that the organization is also included in the userinfo part of the URL:
https://organization-redacted@dev.azure.com/organization-redacted/project/_git/reponame
This is the default format in Azure DevOps. As far as I understand this should make the useHttpPath configuration redundant.
Version
2.5.0+d34930736e131ad80e5690e5634ced1808aff3e2
Operating system
Windows
OS version or distribution
Windows 11 Enterprise
Git hosting provider(s)
Azure DevOps
Other hosting provider
No response
(Azure DevOps only) What format is your remote URL?
https://{org}@dev.azure.com/{org}
Can you access the remote repository directly in the browser?
Yes, I can access the repository
Expected behavior
When running a "git fetch", authentication should work trough our Enterprise Sign on and credential should be stored in Windows credential manager so that I am not asked again to authenticate.
Actual behavior
When running a "git fetch", the authentication should works trough our Enterprise Sign on but the credential is not stored in Windows credential manager and on next "git fetch" I have to log on again.
This happens when I use git-credential-manager from within WSL2 (with Git 2.45.1) as well as when using it in Git for Windows 2.45.1 with explicit configuration "useHttpPath=false".
From the logs (see below) I found that the 'get' command works well, but the 'store' command fails. It seems to me that https://github.com/git-ecosystem/git-credential-manager/pull/1522 only fixed half of the problem.
Output:
Logs
complete log output as captured through WSL:
git credential-manager diagnose
gives [ OK ] for everything.