- Code should be intented per Markdown syntax for a code block. This
matters when this documentation is rendered to HTML
- Fix some innaccurate usage examples
- Tweak wording, formatting in a few places
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.
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.
- Short-form docs for `pr/repo view` no longer say "in browser"
- Long-form docs for all these commands now list more information about
what will be displayed in the terminal, plus stressing out the
alternate behavior with the `--web` flag.
- `--web` flag docs: add English articles
Change from "repo" to "repository". Run "gh repo clone -h` to see the usage text I am referring to.
We use the word "repository" here:
Usage:
gh repo fork [<repository>] [flags]
Usage:
gh repo view [<repository>] [flags]
Explicitly assign the writer stream for the progress spinner so that
tests may override it.
The default when not in testing stays the same: the output stream is the
colorable stdout.
The 2nd argument now unused since we've determined that, in practice, we
can safely fetch git objects from a freshly created fork on GitHub and
that we don't need the remote URL-swapping workaround.
