Credential Manager Core not a git command. See git --help .

[javaniecampbell]

Which version of GCM Core are you using?

From a terminal, run git-credential-manager-core version and paste the output.

Git Credential Manager version 2.0.164-beta+1264f234c7 (Windows, .NET Framework 4.0.30319.42000)

Which Git host provider are you trying to connect to?

• Azure DevOps
• Azure DevOps Server (TFS/on-prem)
• GitHub
• GitHub Enterprise
• Bitbucket
• Other - please describe

Can you access the remote repository directly in the browser using the remote URL?

From a terminal, run git remote -v to see your remote URL.

origin https://github.com/javaniecampbell/one-ui-tailwind.git

• Yes - as long as I am signed to my GitHub a/c as it is a private repo
• No, I get a permission error
• No, for a different reason - please describe

---

[Azure DevOps only] What format is your remote URL?

• Not applicable
• https://dev.azure.com/`{org}`/...
• https://{org}@dev.azure.com/{org}/...
• https://{org}.visualstudio.com/...

[Azure DevOps only] If the account picker shows more than one identity as you authenticate, check that you selected the same one that has access on the web.

• Not applicable
• I only see one identity
• I checked each identity and none worked

---

Expected behavior

I am authenticated and my Git operation completes successfully.

Actual behavior

After attempting to do a git operation e.g. git pull it threw an error as shown below:

$ git pull
git: 'credential-manager-core' is not a git command. See 'git --help'.
git: 'credential-manager-core' is not a git command. See 'git --help'.
Already up to date.

Logs

Set the environment variables GCM_TRACE=1 and GIT_TRACE=1 and re-run your Git command. Review and redact any private information and attach the log.

$ git push
git: 'credential-manager-core' is not a git command. See 'git --help'.
git: 'credential-manager-core' is not a git command. See 'git --help'.
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 368 bytes | 92.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://github.com/javaniecampbell/one-ui-tailwind.git
   cfb7ae0..6a555ed  master -> master

[dscho]

This sounds as if GCM Core was not installed correctly into your Git's libexec path. What does git --exec-path show? Do you see git-credential-manager-core.exe in that folder? If not, can you find where it was installed instead?

[scivision]

I have the same error on my system:

• C:/Program Files/Git/mingw64/libexec/git-core/git.exe
• C:\Program Files (x86)\Git Credential Manager Core\git-credential-manager-core.exe

The installer added to my ~/.gitconfig:

[credential]
	helper = ""
	helper = manager-core
[credential "https://dev.azure.com"]
	useHttpPath = true

I made a softlink for git-credential-manager-core.exe to the libexec directory where git.exe is. Then a git push results in error

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Git.CredentialManager, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
at Microsoft.Git.CredentialManager.Program.Main(String[] args)

I then uninstalled this program and went back to GCM 1.20 (which did work and now still works), which puts in ~/.gitconfig, and is installed in the same directory above as git.exe:

[credential]
	helper = manager

[mjcheetham]

Hi @scivision,

Can you please check if C:\Program Files (x86)\Git Credential Manager Core has been added to your %PATH%?
The .exe installer should do this for you. You may need to close your current command prompt window and open a new one to get the updated environment variables.

[scivision]

Yes it was, I forgot that Windows Terminal needs to be completely closed (all tabs) to update PATH in a new tab. So that was it, close/open Windows Terminal and GCM Core works. Thanks!

[mjcheetham]

Glad to hear you got things working! 🥳 Please let us know if you encounter any issues with GCM Core, and thanks again for trying GCM Core out.

FWIW we're updating the %PATH% via Environment.SetEnvironmentVariable(...)...

https://github.com/microsoft/Git-Credential-Manager-Core/blob/c763ca00ab05d08b15d7022a93a88e4fee859a11/src/shared/Microsoft.Git.CredentialManager/Application.cs#L148-L162

https://github.com/microsoft/Git-Credential-Manager-Core/blob/a71aee752b33c868d30f756585eedacc665e7d43/src/shared/Microsoft.Git.CredentialManager/Interop/Windows/WindowsEnvironment.cs#L25-L46

..which, according to documentation here:

If target is EnvironmentVariableTarget.User, the environment variable is stored in the HKEY_CURRENT_USER\Environment key of the local computer's registry. It is also copied to instances of File Explorer that are running as the current user. The environment variable is then inherited by any new processes that the user launches from File Explorer.

Similarly, if target is EnvironmentVariableTarget.Machine, the environment variable is stored in the HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment key of the local computer's registry. It is also copied to all instances of File Explorer. The environment variable is then inherited by any new processes that are launched from File Explorer.

If target is User or Machine, other applications are notified of the set operation by a Windows WM_SETTINGCHANGE message.

If Windows Terminal listens to WM_SETTINGSCHANGE messages it should be able to reload the current user and machine environment.

[mjcheetham]

Just to follow up @scivision, looks like Windows Terminal is only listening for changes to the system theme (light/dark mode) and not other environment changes:

https://github.com/microsoft/terminal/blob/99fa9460fd8546f0a7dc89016e46c04cf68fe921/src/interactivity/win32/windowproc.cpp#L338-L343

An issue with a feature request to add this is already open on the Windows Terminal: microsoft/terminal#1125.

[TBBle]

Windows Terminal as of 1.3, (new since the previous comment) always refreshes the env-vars for a new tab, i.e. same behaviour as "File Explorer", new children will get the new env. So it doesn't need to react to WM_SETTINGSCHANGE in this case.

For the existing session, the shell, e.g. PowerShell, Microsoft PowerShell, CMD, would need to update its own environment block by reacting to WM_SETTINGSCHANGE, as Windows Terminal can't (and shouldn't) push down a new set of environment variables to a running shell. It seems unlikely this would happen automatically, unless the shell was tracking which env-vars had been locally changed by the user, and ignoring or merging the result. And this would be a surprising behaviour, I think.

There are tools like refreshenv from Chocolatey that will update all the env-vars in a running PowerShell or CMD, but they're pretty heavy-handed and lose local changes to thing like TMP.

[Hussainbabatunde]

i tried pushing a project on github but i am getting a git-credential-manager-core.exe error. it is saying i need to install .NET framework, version=v4.7.2. But my system doesnt support that version. i have installed .NET framework runtime version 4.6.2 but the error still persists

[dscho]

i tried pushing a project on github but i am getting a git-credential-manager-core.exe error. it is saying i need to install .NET framework, version=v4.7.2. But my system doesnt support that version. i have installed .NET framework runtime version 4.6.2 but the error still persists

This is not at all the same issue as was reported in this ticket.

Please open a new ticket, and provide important information such as your Windows version.

[arturohernandez10]

I have the exact same issue. With any command that involves connecting to the server. To fix it I just uninstalled and reinstalled Git using choco. And I still get the same error.

git: 'credential-manager' is not a git command. See 'git --help'.

This command would actually fail

λ git push --set-upstream origin QA/mycommit -v            
Pushing to https://github.com/account/repo.git       
git: 'credential-manager' is not a git command. See 'git --help'.  
                                                                   
The most similar command is                                        
        credential-manager-core                                    
fatal: QA/mycommit cannot be resolved to branch            

Eventually I did this:

git config --global push.default current
push -u

Then, I only got the git: 'credential-manager' is ..... error. But this time my code made it through. I use Cmder as my console. And I notice git-credential-manager-core.exe shows up in the status bar. So it is getting executed. The error is just wrong...

[TBBle]

@arturohernandez10: This sounds like a different problem. the initial issue in this ticket was Git was trying to run git-credential-manager-core and not finding it, your output indicates it's trying to run git-credential-manager which is the executable from the older https://github.com/microsoft/Git-Credential-Manager-for-Windows.

I suspect the Cmder status bar is a red-herring, it's probably triggered by git populating the "most similar command" list.

So I'd suggest opening a new issue, and as well as the other required information, include the output of git config --show-origin credential.helper which I guess will help diagnose your issue.

[dscho]

git: 'credential-manager' is not a git command. See 'git --help'.

I guess that the riddle can be solved by running git config --show-origin --get-all credential.helper.

λ git push --set-upstream origin QA/mycommit -v
Pushing to https://github.com/account/repo.git
git: 'credential-manager' is not a git command. See 'git --help'.

The most similar command is
credential-manager-core
fatal: QA/mycommit cannot be resolved to branch

That QA/mycommit cannot be resolved to branch is the most likely culprit here: you seem to want to push the QA/mycommit branch but it does not exist locally.

[DadiAnas]

I just removed this section:

[credential]
	helper = manager-core

from this file /usr/local/etc/gitconfig.

[whoisj]

This may be helpful to somebody in the future. My system started getting this issue this morning, and this thread helped me to resolve it. Here's what I did (sharing incase it helps anyone else).

Using @dscho's very helpful command I could see that there was a mismatch between global and system configurations.

git config --show-origin --get-all credential.helper
file:C:/Program Files/Git/etc/gitconfig manager-core
file:C:/Users/whoisj/.gitconfig credential-manager-core

By modifying the global config via git config --global --edit to either not contain the entry OR by changing the entry to match the system config (in this case changing credential-manager-core to manager-core) immediately resolved my issue.

Thanks to @dscho for the suggestion.

[Quetzalcohuatl]

Running this fixed it for me:

git config --global --unset credential.helper

It sounds scary. But it still asks me to authenticate, so I think we're good.

[akovov]

I simply cloned git-credential-manager-core.exe to git-credential-manager.exe and that's resolved the issue, because in trace were seen that at beginning it asks for credential-manager-core and then only credential-manager

[paulsm4]

I had exactly the same problem after upgrading to Git 2.38/Windows/64
CAUSE: mismatch between global Git config (which now has [credential] helper=manager-core) and user .gitconfig (which retained old [credential] helper=manager).
SOLUTION: Git bash > vi ~/.gitconfig >
<= Changed user "'[credential] helper" to "manager-core"
Worked like a charm!

[bakoontz2]

I realize this is closed but it's the first hit I got when searching for "...Core not a git command..." so I'll add my USD0.02 here.

I run git under Cygwin. Installing version 2.0.935 of the Credential Manager Core (Windows version) does not update /usr/libexec/git-core. The fix is to create a symlink:

ln -s /cygdrive/c/Program\ Files\ \(x86\)/Git\ Credential\ Manager/git-credential-manager.exe

Now the executable is found by git and the credentials are accessed accordingly.

(If you create a link to git-credential-manager-core.exe you get a silly warning about files being renamed. Apparently git and GCM are out of sync on this.)

[psulek]

After installing Git Credendial Manager Core, in my git config file C:\Users\USER\.gitconfig:

[credential]
	helper = manager-core
	helper = 
	helper = C:/Users/USER/AppData/Local/Programs/Git\ Credential\ Manager/git-credential-manager.exe

helper points to some invalid path C:/Users/USER/AppData/Local/Programs/Git\ Credential\ Manager/git-credential-manager.exe.

so i manually found path and valid path on disk to be c:/Users/USER/AppData/Local/Programs/Git Credential Manager/git-credential-manager.exe and update C:\Users\USER\.gitconfig:

[credential]
	helper = manager-core
	helper = 
	helper = c:/Users/USER/AppData/Local/Programs/Git Credential Manager/git-credential-manager.exe

Now helper finally ask for credentials.

[dscho]

	helper = C:/Users/USER/AppData/Local/Programs/Git\ Credential\ Manager/git-credential-manager.exe

This should work, though, as Git interprets backslash characters as escape characters in the Git config, see https://git-scm.com/docs/git-config#_syntax for more information.

Something strange is going on in your setup that disagrees with the documentation.

[psulek]

@dscho you are right. I run git-credential-manager.exe configure and get helper = C:/Users/USER/AppData/Local/Programs/Git\ Credential\ Manager/git-credential-manager.exe so i guess thats correct (escaping space in directory name via \ .

But i cant get git credential manager to ask me for credentials into our azure devops on-promise with such config :-(

my git config is like:

[credential]
    helper = manager-core
	helper = 
	helper = c:/Users/User/AppData/Local/Programs/Git\\ Credential\\ Manager/git-credential-manager.exe

[push]
	autoSetupRemote = true
[credential "https://our.company.devops.local"]
	useHttpPath = true
[credential "https://dev.azure.com"]
	useHttpPath = true

[psulek]

@dscho it seems it was useHttpPath set to true for me that was causing problems becuase our on-premise devops does not need this, according to this info.