When executing `gh pr re` (note the incomplete command name), Cobra
would just display the help text for `gh pr` on standard output, exit
with status 0, and not print any message that you have mistyped the
"re" subcommand. Each part of this behavior is wrong.
This workaround makes sure that the helpful error message is printed on
stderr:
$ gh pr re
unknown command "re" for "gh pr"
Did you mean this?
reopen
ready
review
However, the exit status is still 0, whereas it should be non-zero.
Since `HelpFunc` does not return an error argument, we cannot trigger an
error status from this workaround.
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.
