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.
Any errors from fetching and rendering the README were silenced and
ignored in `repo view`. This change:
- Tolerates HTTP 404, but will raise exceptions for any other error;
- Moves markdown rendering from `api` package to command implementation;
- Ensures markdown rendering errors are correctly reported.
First, consolidate the functionality between `pr merge` and `pr
checkout` that resolves the default branch name of the base repo. With
an added bonus, the new approach avoids an API request when one isn't
necessary.
Then, ensure that checking out 3rd-party PRs will result in local branch
name such as `<owner>/<branch>` when the head branch of the repository
matches the default branch of the base repository. We already have had
code in place to take care of this, but it only took effect in the `pr
checkout <number>`-style invocation.
This code was put in place in preparation for a feature that never
shipped. Namely, we wanted to use the commit hash for the base branch so
we can get an accurate `git log` involving the changes in a pull
request. However, getting the commit hash from API is not the way to go
because the latest commit might not be available in the person's local
repository, and using a local tracking branch for base such as
`origin/master` works quite well in most cases without dereferencing it.
This API was just fixed in github.com, but it will take a while for the
change to propagate to GitHub Enterprise installs, so guard ourselves
from false positives when querying forks.
