After completing the interactive `gh auth login` flow, the `hosts.yml`
config file will have been populated with both `oauth_token` and `user`
properties for the GitHub host. However, after `auth login --with-token`
only the `oauth_token` is persisted but no username.
This fixes `auth git-credential` behavior so it allows authentication
even if the `user` property is missing. It's entirely optional to send a
proper username for git authentication, since GitHub seems to ignore the
actual value sent and just focuses on the token itself.
* Allow `gh auth git-credential` to authenticate GitHub Gist requests
When there are stored credentials for `example.com`, allow using them to
authenticate requests to `gist.example.com` as well.
* Fix writing out of credential config
* remove unneccessary function
* actually delete
Co-authored-by: nate smith <vilmibm@github.com>
Fixes non-interactive login flow and make sure "prompt" configuration is
respected by never prompting if it was explicitly disabled.
No longer asks to press Enter again after "Authentication complete"
message, since that didn't provide any value to the user.
Adds a new command `gh auth setup-git [<hostname>]` that sets up git to
use the GitHub CLI as a credential helper.
The gist is that it runs these two git commands for each hostname the
user is authenticated with.
```
git config --global --replace-all 'credential.https://github.com.helper' ''
git config --global --add 'credential.https://github.com.helper' '!gh auth git-credential'
```
If a hostname flag is given, it'll setup GH CLI as a credential helper
for only that hostname.
If the user is not authenticated with any git hostnames, or the user is
not authenticated with the hostname given as a flag, it'll print an
error.
Co-authored-by: Mislav Marohnić <mislav@github.com>
When there was a previously valid token that was granted some scopes,
ensure all those scopes will be re-requested when doing the
authentication flow for the new token.
This is to avoid hitting the filesystem and resolving symlinks
unnecessarily. The value of executable is just used conditionally by a
handful of commands.
There was a bug where if git was not installed then gh would do its
authentication and try to configure git but would then find out that the
git executable was not in PATH.
Now gh checks to see if the git executable is in PATH before
authenticating the user. If the git executable is in PATH the
authentication continues as normal, if it is not in PATH then it prints
out an error to the console:
$ git executable not found in $PATH
Resolves: #3818
