* after merge, switch to base branch if available
* Add ability to checkout new branch
* Style cleanup
Co-authored-by: Sam Coe <samcoe@users.noreply.github.com>
Conditions prohibiting a regular merge: BLOCKED, BEHIND, DIRTY.
Conditions triggering a regular merge even if `--auto` was set: CLEAN,
HAS_HOOKS.
Note that UNKNOWN status does not trigger either of the conditions.
When passing `--auto` flag, only schedule an auto-merge if
the `mergeStateStatus` field is "BLOCKED".
This ensures that a PR will always be merged when passing `--auto` even
if it doesn't have required checks or if checks have already passed.
This avoids loading authorship information for git commits, since it
relies on a GraphQL API that wasn't available before GHE v3.0. The
authorship information wasn't necessary for the merge operation anyway;
just loading the last commit OID was.
This completely rewrites the PR lookup mechanism so that the caller
must specify the GraphQL fields to query for each PR. Additionally, this
fixes some export problems with `pr view --json`.
Features:
- Each pr command now gets assigned a concept of a Finder. This makes it
easier to stub the PR in tests without having to stub the underlying
HTTP calls or git invocations.
- `pr view --web` is much faster since it only fetches the "url" field.
- `pr diff 123` now skips a whole API call where a whole PR was
unnecessarily preloaded just to access its diff in a subsequent call.
- PullRequestGraphQL query builder is now used to construct queries.
- A bunch of individual commands are now freed of having to know about
concepts such as BaseRepo, Branch, Config, or Remotes.
For single-commit PRs, the commit subject will be the subject of the
head commit and the PR number. For multi-commit PRs, the commit subject
will be the PR title and PR number. Instead of trying to replicate this
logic client-side, omit the `commitHeadline` param and let the server
apply defaults appropriately.
Reverts https://github.com/cli/cli/pull/1627
For asserting command output, exact string matches are preferred in most cases. In cases when a pattern match is needed, the test can use regexp ad hoc.
For operations such as closing an issue or merging a PR, we would
display the success icon (a checkmark) in red and magenta colors,
respectively, to reflect the latest state of the record operated on
(red: closed; magenta: merged).
This was always confusing to me, seeing it both in code and in the UI,
because I'm instinctively thinking that it's a bug and have to remind
myself that it's by design.
