When using a push.default = current triangular workflow, apart from
using @{push} to determine the remote branch name, we should also follow
the
1. branch.<name>.pushRemote
2. remote.pushDefault
3. branch.<name>.remote
...list to determine which remote Git pushes to.
When push.default is not 'upstream' / 'tracking' (or 'nothing'), we can
expect local and remote branch names to be the same and solely rely on
@{push} or RemoteURL.
This fixes the wrong error message 'no pull requests found for branch
"<target branch>"' when the local branch is not pushed in the
push.default = simple / current and upstream = <target branch> setup.
When using a push.default = current central workflow [1], we should use
@{push} instead to locate the remote branch.
In fact, @{push} covers most cases in push.default = upstream too. The
branch.<name>.merge is probably only needed when using RemoteURL and
different remote / local branch names.
[1] https://github.com/tpope/vim-fugitive/issues/1172#issuecomment-522301607
Closes#10013
This commit enhances `gh pr checks` to exit with an error when mutually exclusive `--json` and `--watch` flags are used. Users are encouraged to either 1) retrieve information about the checks via `--json` or 2) watch and wait on PR checks that are being updated.
You need to know exact `baseRefOid` so you could show correct diff.
`baseRefName` is not enough sometimes because branch from which PR was
forked might have changes already.
Example usage:
```
gh pr view --json headRefName,headRefOid,number,baseRefName,baseRefOid,reviewDecision
```
IsEnterprise currently returns `true` when `IsTenancy` returns true. We
prefer that this behavior is orthogonal. This commit adds failing tests to
the instances where IsEnterprise should not behave the same as IsTenancy.
These test cases are expected to pass with the inclusion of the coming
improvements to go-gh to handle the orthogonality of IsEnterprise and
IsTenancy.
Currently, the prompter doesn't enforce the requirement of a title for PR
and Issue creation. However, that creates the UX where a user can enter a
blank title, spend time filling out a detailed body, then fail to create
the issue or pr when the request is sent to the api because the title is
blank. This attempts to handle that before sending a request to the api,
enforcing that, when prompting, the title of an issue is not blank.
While the `state` field corresponds 1:1 with different GitHub Actions
states, the `bucket` field is an abstraction of the CLI that lacked
documentation. This both adds documentation about the existence of the
`bucket` field and enumerates the possible values.
