When applying metadata to the new PR such as assignees or reviewers, if
the operation fails, an error message would get printed:
failed to create pull request: <API error text>
This was misleading, because the PR did get created; it's just that
updating it failed. The new error message is:
https://github.com/OWNER/REPO/pull/123
pull request update failed: <API error text>
The PR URL is printed on stdout and the error message is printed on
stderr. In case of any errors, the exit code is still non-zero.
If the `--repo` flag is specified, then the user intends to select a
repository other than the current one. In that case, it doesn't make
sense to fall back to detecting the PR belonging to the current branch,
so throw a descriptive error instead.
The problem was that opts.confirmSubmit was mutated before reaching doSetup. This commit creates a copy of the initial confirmSubmit value. So the doSetup receives the initial data passed from the command, not the mutated one.
This ensures that while having git remotes to point to either
`github.com` or authenticated GHE instances, adding another git remote
pointing to an unrelated host won't change the remote resolution in any
way, even if the unrelated remote is called `upstream` or `github` (and
thus normally took precedence).
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
