First `git push` fails with GCM if multiple credentials exist; second push succeeds

[reponemec]

Summary

When using Git on Windows 10 with Git Credential Manager (GCM) and pushing to a GitLab remote over HTTPS, my first git push consistently fails with an authentication error. However, the second git push (immediately after) always succeeds.

---

Environment

• OS: Windows 10
• Git Client: Git Bash (also reproducible from Visual Studio)
• git version 2.39.1.windows.1
• Git Credential Manager version: 2.0.886+ea93cb5158
• Credential Helper: manager
• Remote: GitLab over HTTPS

---

What happens

Step-by-step:

1. First git push fails:

   remote: HTTP Basic: Access denied [...]
   fatal: Authentication failed for 'https://gitlab.com/...' 
   

2. Second git push succeeds immediately without any prompts or changes.

---

Investigation

I have both of these credentials stored:

• A gitlab-ci-token (most likely added by my local GitLab Runner)
• My personal GitLab PAT with username nemecgitlab

Running credential checks confirms this:

printf "protocol=https\nhost=gitlab.com\n\n" | git credential-manager get

→ returns gitlab-ci-token

printf "protocol=https\nhost=gitlab.com\nusername=nemecgitlab\n\n" | git credential-manager get

→ returns my correct PAT

I then added this config explicitly:

git config credential.username nemecgitlab

After that, the first push always works.

---

Key Insight

Based on Git trace logs and behavior, it appears GCM tries both credentials in sequence:

• First: gitlab-ci-token → fails (unauthorized)
• Then: nemecgitlab → succeeds

However, Git still returns the error from the first attempt, and the push is aborted.
On the next push, GCM reuses the previously successful credential, so it goes through without error.

It seems GCM identifies the correct token in the first attempt, but this is not reflected in Git’s handling of the result.

---

Expected behavior

If GCM successfully authenticates with a fallback credential, it should not abort the Git operation based on the earlier failure.

---

Question

Is this behavior expected? Or could it be improved so that the first successful credential attempt (even if preceded by a failure) is honored for that same push?

Thanks!

(For context: GitLab support suggested reporting this here → https://gitlab.com/gitlab-org/gitlab/-/issues/534583)