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.
Before: the default push target for the current branch in `pr create`
was the first repository found among git remotes that has write access.
Now: the default push target is the fork the base repo, if said fork
exists and has write access, falling back to old behavior otherwise.
This change in the default is to facilitate contributions to projects
that have a hard requirement that all pull requests (even those opened
by people with write access to that project) come from forks.
I didn't initially use GitHubRepo because it had the weird error
wrapping. I poked around and I think this function is leftover from a
vestigial GitHubRepoID function that used to be more single-purpose. I
took out the weird error handling so it could be reused and then used it
from the new GitHubRepoExists.
