Accept the "HOST/OWNER/REPO" syntax or passing a full URL for both the
`--repo` flag and the GH_REPO environment variable and allow setting
GH_HOST environment variable to override just the hostname for
operations that assume "github.com" by default.
Examples:
$ gh repo clone example.org/owner/repo
$ GH_HOST=example.org gh repo clone repo
$ GH_HOST=example.org gh api user
$ GH_HOST=example.org gh gist create myfile.txt
$ gh issue list -R example.org/owner/repo
$ gh issue list -R https://example.org/owner/repo.git
$ GH_REPO=example.org/owner/repo gh issue list
This commit hacks the existing repo clone tests into something usable by
the new isolated command. It went ok and was less effort than trying to
introduce the same kind of test format as repo view and gist create.
After a person copies `hosts.yml` to a headless system, they will still
be forced to go through re-authentication flow unless they copy or
initialize a `config.yml` as well. This fixes respecting authentication
info from `hosts.yml` even if `config.yml` is missing.
Read from and write to the `hosts.yml` file every time `config.yml` is
accessed. Everything that before went under the `hosts:` map now belongs
to `hosts.yml`.
We dynamically add hosts on `Set`, so this `hosts` cache might fall out
of date. We could ensure to keep it updated, but I'm not convinced it's
necessary for speed right now.
Previously we would trigger OAuth flow when the config file did not
exist. Now we will let an empty Config object be initialized in that
case, but trigger OAuth flow when the Context caller requests an
AuthToken.
The login name of the authenticated user will be readily available only
if authentication info comes from the config file. With other upcoming
authentication modes (for example, the GITHUB_TOKEN environment
variable), the token is the only piece of information we got, so we
would need to additionally query for the login name.
Since `issue status` and `pr status` are the only commands that need the
name of the authenticated user right now, have those commands explicitly
query for the login name. This results in an additional API query, but
simplifies Context implementation and future authentication approaches.
