Our code had an unspoken assumption that only one apiClient is created
during the course of a command. Violating this assumption is fine in
almost all cases, but not when we need to do a re-auth to add a new
oauth scope to a user's token.
There is likely a more elegant solution to the problem but until then
this changes determineBaseRepo to use an existing apiClient.
Our code had an unspoken assumption that only one apiClient is created
during the course of a command. Violating this assumption is fine in
almost all cases, but not when we need to do a re-auth to add a new
oauth scope to a user's token.
There is likely a more elegant solution to the problem but until then
this changes determineBaseRepo to use an existing apiClient.
How this works for people with existing OAuth tokens:
$ gh issue list -L1
Notice: additional authorization required
Press Enter to open github.com in your browser...
[auth flow in the browser...]
Authentication complete. Press Enter to continue...
Showing 1 of 132 issues in cli/cli
...
Users of Personal Access Tokens get a different notice:
Warning: gh now requires the `read:org` OAuth scope.
Visit https://github.com/settings/tokens and edit your token to enable `read:org`
or generate a new token and paste it via `gh config set -h github.com oauth_token MYTOKEN`
Per code documentation: "BasicClient returns an API client that borrows
from but does not depend on user configuration". This means that any
errors while reading `oauth_token` should be tolerated.
this adds recognition of the git_protocol setting when:
- creating a repo
- cloning a repo
- forking a repo
- forking/pushing during pr create
- checking out a PR
additionally, it:
- consolidates remote adding to use AddRemote; this introduces a fetch
where there previously hadn't been one
- changes repo clone to accept an ssh url
- changes repo fork to accept an ssh url
i just added basic unit tests; adding new test cases for all of the
above scenarios seemed like diminishing returns.
- adds config get and config set commands
- supports arbitrary k/v strings set at top and host level
- supports writing an updated config, preserving comments
- supports mostly lazy evaluation of yaml
This compensates for what appears to be a bug in Cobra, which only
handles `pflag.ErrHelp` unless the error is wrapped. It also might be
that Cobra doesn't recognize Go 1.13-style error wrapping.
