Github vs. GitHub Enterprise + GCM modalPrompt vs. store

[dayglojesus]

Hi,

This is a long standing issue that only surfaced for us recently.

We leverage the GCM CLI to automatically pre-populate Github and Github Enterprise credentials for some users.

Github:

PS C:\Users\the.user> git credential-manager store
protocol=https
host=github.com
username=some-account
password=personaltoken
\r\n

GHE:

PS C:\Users\the.user> git credential-manager store
protocol=https
host=our.ghe.local
username=the-user
password=personaltoken
\r\n

This methodology worked for us until we deployed a version >= 1.15 where GCM introduced a new feature, #547 "Respect Usernames in Repository URLs". Prior to version 1.15, the URLs stored by GCM, did not contain a username and as such, Git operations (i.e. clone, pull, etc) on URLs that also do not contain a username, worked...

Example: git clone https://our.ghe.local/the-user/some_repo.git

After version 1.15, the only way to perform a clone in this manner and not be prompted for credentials (aka get GCM to recognize the target Git URL) is to add the username.

Example: git clone https://the-user@our.ghe.local/the-user/some_repo.git

This represents a significant shift in behaviour and is made more confusing because setting host=github.com behaves differently than any other host. I assume this is because public Github does not support the https://username@host URL scheme and is therefore given a pass.

However, it is interesting to note that in the absence of matching credentials, setting them using the modalPrompt functions normally and creates an appropriate URL.

Full Example for GCM >= 1.15

1. Add the GHE credentials using git credential-manager store per above
2. git clone https://our.ghe.local/the-user/some_repo.git fails, but induces the modalPrompt
3. Enter username and password
4. GCM stores the credentials correctly using no username in the URL

This is impractical for automation, but I have only found one workaround so far...

git config --global credential.microsoft.visualstudio.com.username the-user

But this has the unfortunate drawback described here.

Still, given the discrepancy between how the modalPrompt and the store function operate, I am not sure whether this is a bug or expected behaviour.

Perhaps there are some other workarounds?

Thanks!