After successfully authenticating with GitHub CLI #1413, we could potentially prime the user's git credential cache with a token that can be used for git clone/push/pull operations.

What this solves: users would no longer get another authentication prompt (this time from git, but the user typically doesn't know that) right after they've authenticated gh and ran something like gh repo clone myrepo. Furthermore, if the user has 2FA enabled, even though the git prompt asks them for their github.com password, their actual password will not work and they will have to generate a Personal Access Token. However, at this point in GitHub CLI we already have a token for them that is valid for git operations.

How this would work, roughly:

$ git config --global credential.helper
osxkeychain

$ git credential-osxkeychain
usage: git credential-osxkeychain <get|store|erase>

# getting an existing token
$ git credential-osxkeychain get <<<"host=github.com
protocol=https"

password=TOKEN
username=mislav

# setting a new token (old one needs to be `erase`d first)
$ git credential-osxkeychain store <<<"host=github.com
protocol=https
username=mislav
password=NEWTOKEN"

See https://git-scm.com/docs/git-credential

Risks:

• With Git for Windows and its default credential helper, requesting a cached credential could spawn a graphical window asking to log into GitHub if there is no stored credential. We would definitely want to avoid that.
• Depending on OS permissions and the configured credential helper, gh executable might not have the privileges to check or store git credentials.
• There might be no credential helper configured for the user on Linux. In those cases, it would be hard to pick a default for a user, so we should probably bail out in that case, but we could provide the user with some pointers.