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.
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.
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.
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.
For metadata types chosen in interactive flow, we fetch all records from
the API in order to be able to display a multi-select interface.
For metadata defined via command-line flags, we resolve records that can
be looked up directly, avoiding fetching the entirety of expensive
datasets (e.g. all members of an organization) if we can.
The new approach ensures efficient fetching when interactive flow is
combined with values from flags.
We no longer guess the head repository using heuristics; instead, we
present the user with the choice of pushable repositories and an
additional option to create a new fork.
The new `pr create --head` flag is available for the user to specify the
head branch in `branch` or `owner:branch` format and completely skip any
forking or auto-pushing checks.
