If any of the repositories named by git remotes could not be found via
API lookup, a "could not resolve to a Repository" error would be thrown,
but the goal of the base repo logic was to ignore NOT_FOUND errors.
Any gh command that has invoked NewCachedHTTPClient has also
inadvertently enabled caching for the original `http.Client` due to the
nature that NewCachedHTTPClient mutates the original argument passed.
A new GitHub feature landed where the API client can specify the desired
name of the new fork. This avoids the necessity of subsequently having
to rename the forked repo after the fork operation has created one.
For backwards compatibility, the renaming logic is still here, but
activates only if the resulting repo name is not the desired name.
* Fix obtained scope mapping to include missing scopes
As is, `gotScopes` does not contain certain scopes because it doesn't check for the "special" scopes that imply other scopes. For example, the `repo` scope implies `repo:invite`.
* Add a comment in ScopesSuggestion explaining branch statements
* Delete whitespace to appease go-fmt
If `gh release create <TAG>` was called and TAG exists locally but not on the remote, this warns about the unpushed tag to avoid recreating it on the remote. The user can pass a value for `--target` to silence the warning.
If the base branch has no minimum approval requirements, show "N Approved"
reviews. Otherwise, show "N/X Approved".
Co-authored-by: Mislav Marohnić <mislav@github.com>
Whenever a SSO challenge gets issued by the server by means of a URL in
the `X-GitHub-SSO` response header, gh now additionally prints that URL
on the standard error stream.
This is achieved by installing a middleware to all HTTP requests and
storing the server challenge to a value accessible by `factory.SSOURL()`.
Such approach was made necessary mainly because of the
`shurcool-graphql` client which doesn't give access to response headers
when a GraphQL error case is encountered.
The milestone filter in the `Repository.issues` GraphQL connection is
broken, so switch to the Search API for any milestone filtering.
Previously, we used to work around this by obtaining the milestone
database ID from decoding the GraphQL ID, but that no longer works since
the GraphQL ID format has changed.
