Find PRs using @{push}
#9208
Find PRs using @{push}
#9208
Conversation
Frederick888
force-pushed
the
find-pr-by-rev-parse-push
branch
8 times, most recently
from
cdc1b5d to
4226579
Compare
cliAutomation
added
the
external
Frederick888
force-pushed
the
find-pr-by-rev-parse-push
branch
from
4226579 to
c8a51dd
Compare
|
Wow this is an oooooold issue. Thank you for your contribution. The details of the original issue look quite involved, so it may take me some time to fully grok and review this. Cheers. |
|
Hey @Frederick888, can you provide some more context about the end-to-end workflow here? I believe this relates to triangular workflows where there are 2 remotes, one configured for push and one for fetch but I think I'm missing something in my understanding. Here's what I tried locally: Clone my fork and check the remotes: Configure the triangular workflow: Create a PR from my fork using the syntax mentioned by Mislav: Then I expect using But I anticipated that this PR would fix it: So what am I misunderstanding? Thanks! |
|
Ah, perhaps what I'm missing is that when we create the local branch it needs to be checked out from the upstream? Deleting the old branch: Creating a new branch from Showing the difference between current release and this PR: Is this expected behaviour? I'm trying to figure out why it would be important to |
|
I think the issue here is that when the branch starting point doesn't contain a remote, then the Which is an issue for https://github.com/cli/cli/pull/9208/files#diff-ccedca01e076cd065987253b366873ca2bee2e28c9d0bc13d50d7b7795c0bf4eR328 I guess the solution to this would be as Mislav suggested:
But that seems out of scope for this, if I understand your goal correctly. Do I understand this correctly @Frederick888? |
It's actually related to both central workflow and triangular. First of all, make sure you've done Central: $ git clone https://github.com/Frederick888/playground.git
Cloning into 'playground'...
remote: Enumerating objects: 164, done.
remote: Counting objects: 100% (68/68), done.
remote: Compressing objects: 100% (39/39), done.
remote: Total 164 (delta 40), reused 55 (delta 29), pack-reused 96
Receiving objects: 100% (164/164), 39.82 KiB | 1.99 MiB/s, done.
Resolving deltas: 100% (56/56), done.
$ cd playground
$ git checkout --guess test-diff
branch 'test-diff' set up to track 'origin/test-diff'.
Switched to a new branch 'test-diff'
$ git branch --set-upstream-to origin/master
branch 'test-diff' set up to track 'origin/master'.
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://github.com/Frederick888/playground.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "test-diff"]
remote = origin
merge = refs/heads/master
# with my patch
$ gh pr view
test diff Frederick888/playground#7
Draft • Frederick888 wants to merge 4 commits into master from test-diff • less than a minute ago
+8 -1 • - Checks pending
[ ... ]
View this pull request on GitHub: https://github.com/Frederick888/playground/pull/7
# trunk 0df5596512ad44dec74ab3dc07a4e6ea3a7c78fc
$ ~/Programming/Go/gh-cli/bin/gh pr view
no pull requests found for branch "master"Triangular: $ git clone https://github.com/cli/cli.git
Cloning into 'cli'...
remote: Enumerating objects: 54449, done.
remote: Counting objects: 100% (1458/1458), done.
remote: Compressing objects: 100% (817/817), done.
remote: Total 54449 (delta 811), reused 1155 (delta 629), pack-reused 52991
Receiving objects: 100% (54449/54449), 29.40 MiB | 6.75 MiB/s, done.
Resolving deltas: 100% (36967/36967), done.
$ cd cli
$ git remote rename origin upstream
Renaming remote references: 100% (71/71), done.
$ gh repo fork --remote --remote-name origin
! Frederick888/cli already exists
✓ Added remote origin
$ git config branch.trunk.pushremote upstream
$ git config remote.pushdefault origin
$ gh repo set-default cli/cli
✓ Set cli/cli as the default repository for the current directory
$ git fetch --all
$ git checkout --guess find-pr-by-rev-parse-push
branch 'find-pr-by-rev-parse-push' set up to track 'origin/find-pr-by-rev-parse-push'.
Switched to a new branch 'find-pr-by-rev-parse-push'
$ git branch --set-upstream-to upstream/trunk
branch 'find-pr-by-rev-parse-push' set up to track 'upstream/trunk'.
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "upstream"]
url = https://github.com/cli/cli.git
fetch = +refs/heads/*:refs/remotes/upstream/*
gh-resolved = base
[branch "trunk"]
remote = upstream
merge = refs/heads/trunk
pushremote = upstream
[remote "origin"]
url = [email protected]:Frederick888/cli.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote]
pushdefault = origin
[branch "find-pr-by-rev-parse-push"]
remote = upstream
merge = refs/heads/trunk
# with my patch
$ gh pr view | cat
title: Find PRs using `@{push}`
state: OPEN
author: Frederick888
labels: external
assignees:
reviewers: (Requested), williammartin (Requested)
projects: The GitHub CLI (Needs review 🤔)
milestone:
number: 9208
url: https://github.com/cli/cli/pull/9208
additions: 246
deletions: 35
auto-merge: disabled
# trunk 0df5596512ad44dec74ab3dc07a4e6ea3a7c78fc
$ ~/Programming/Go/gh-cli/bin/gh pr view | cat
no pull requests found for branch "trunk"When you check out a new branch, there are some similar things you need to do. But the key is, after pushing the new branch, making sure I've got a super-charged
#575 is a bit more than this issue. What Mislav originally mentioned sounds like something What I'm trying to address here however, is a perfectly valid setup. All the info that we need to determine the target / feature branches are already in gitconfig. Git itself understands the setup already. It's only that
So yeah, you were on the right track 👍 |
Frederick888
force-pushed
the
find-pr-by-rev-parse-push
branch
from
c8a51dd to
16eed48
Compare
|
@Frederick888, I started extracting issues to describe each of these enhancements in detail e.g. #9363 I'm having trouble understanding the second commit in this series. It seems like the first commit makes it so that:
And after the second commit it makes it so that:
I don't understand what is expected to happen in this last case. I don't understand what this change is intended to protect. Thanks! |
Actually here it uses
Otherwise it uses current branch AFAIU cli/pkg/cmd/factory/default.go Lines 150 to 158 in 0df5596 Since |
Frederick888
force-pushed
the
find-pr-by-rev-parse-push
branch
from
16eed48 to
3693b51
Compare
|
Ah right, I see. Because I'm trying to imagine whether this could have broken any other
I suppose Do you agree? |
Such users are probably of those who always use
Oh yup, good spot! I absolutely should've added it too. b7521e1 and I'll reword the earlier commit too.
Yes I doubt many users actually use this locally. But still it expects 'all branches having the same name on both ends'. So it conveniently falls into the 'otherwise' category. |
Frederick888
force-pushed
the
find-pr-by-rev-parse-push
branch
2 times, most recently
from
f247b33 to
ad62216
Compare
|
@williammartin Done 😄 (Gonna have to head off soon but let me know if you have other concerns.) |
I also do this! Though I usually lack write access upstream anyway; in my case, it's to make |
|
@jtmcg Going through you comment and reviving my memory :) I have a few (directly or indirectly relevant) questions.
According to the manpage:
It doesn't say that [push]
default = simple
[branch "find-pr-by-rev-parse-push"]
; remote = upstream
; merge = refs/heads/trunk
remote = origin
merge = refs/heads/find-pr-by-rev-parse-push...then it resolves normally: $ g rev-parse --abbrev-ref @{upstream}
origin/find-pr-by-rev-parse-push
$ g rev-parse --abbrev-ref @{push}
origin/find-pr-by-rev-parse-push
+1 on what @benknoble mentioned regarding Though Are there any cases where, maybe due to some limitations from Git, people have to use One example that I have in mind is popular forks like Neovim, MariaDB, etc. They may have a local Finally, is the refactoring work something that can be done on top of this PR? In another word, is merging this PR going to drastically increase the refactoring effort? AFAIU the refactoring is mainly going to remove some hacks and quirks, consolidate the code that locates remote branches, then in the end add Not that I'm eager to snatch that 'Contributor' badge, but I have a personal git config patch that I've been rebasing for some half a year alongside this PR. If it's not too much trouble for you folks, I really hope you can help me wrap this up. FWIW the PR really isn't that big if we exclude the tests: $ g df --stat trunk...@{push} -- '*.go' ':!*_test.go'
git/client.go | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------
git/objects.go | 8 ++++++--
pkg/cmd/pr/shared/finder.go | 18 ++++++++++++------
pkg/cmd/pr/status/status.go | 15 +++++++++------
4 files changed, 93 insertions(+), 32 deletions(-) |
[push]
default = simple
[branch "find-pr-by-rev-parse-push"]
; remote = upstream
; merge = refs/heads/trunk
remote = origin
merge = refs/heads/find-pr-by-rev-parse-pushI must be losing my mind because I cannot see what is triangular about this configuration. The branch name and the |
This may be an issue. The Interestingly, the logic to find whether a PR currently exists doesn't use the same |
It's the same as how people have been using But essentially what I wanted to say was despite the fact that PS: a more complete [push]
default = simple
[remote "upstream"]
url = https://github.com/cli/cli.git
gh-resolved = base
fetch = +refs/heads/*:refs/remotes/upstream/*
[branch "trunk"]
remote = upstream
pushremote = upstream
merge = refs/heads/trunk
[remote "origin"]
url = https://github.com/Frederick888/cli.git
fetch = +refs/heads/*:refs/remotes/origin/*
pushurl = [email protected]:Frederick888/cli.git
[branch "find-pr-by-rev-parse-push"]
remote = origin
merge = refs/heads/find-pr-by-rev-parse-push |
I've been struggling horribly to reason through all of this code, and
after much mental gymnastics I identified the culprit as the overloaded
"branch" string returned by parseCurrentBranch.
This value was either the name of the branch that the PR we're looking for
is associated with, or that name prepended with the owner's name and a :
if we're on a branch, so:
PR branch: featureBranch
branch == "featureBranch"
If on Fork belonging to "ForkOwner"
branch == "ForkOwner:featureBranch"
Since this extra information was bundled up into this single string, it
complicated the responsibilities of parseCurrentBranch's "branch" return
value. Thus, I've teased out "branch" into the new PRRefs struct:
type PRRefs struct{
BranchName string
HeadRepo ghrepo.Interface
BaseRepo ghrepo.Interface
}
This allows the new parsePRRefs function to move all the previous
"branch" string's information into structured data, and allows for a new
method on PRRefs, GetPRLabel(), to create the string that "branch"
previously held to pass into its downstream consumer, namely
findForBranch.
This also allowed for better test coverage, directly connecting the PRRefs
fields to the values contained in the git config. Overall, I am now
confident that this is doing what its supposed to do with respect to my
understanding of the various central and triangular git workflows we are
addressing.
|
Alright, I've been swimming through y'all's feedback and some more learnings that we've pieced together after doing some work against a different branch and have come back to this one. I've done some refactoring for test coverage and I finally like the direction this is going... I'm not going to explain much more for now until I finish tracking down a few bugs, but I've added a lot of info to my commit message that can give some context/motivation for what this change does. Hopefully this is easier to grok and discuss, so as always, if you find something that jumps out to you please highlight it so I can tackle it. Y'all have been awesome through what can only be called this quest, and I'm feeling like we're close 🙂 |
There was a lot of copy-pasta code between the finder and pr status. After some investigation it was clear that the prSelectorForCurrentBranch code was really just a duplicate of the finder's code without actually making the API call for the PR. Since the ParsePRRefs helper had already extracted much of the logic for determining a PR's head ref branch, I was able to reuse it in gh pr status with a small refactor.
Due to the refactor of BranchConfig, the tests for `pr create` no longer require a handful of stubbed git commands. Additionally, I noticed some overlap between `pr create`'s existing logic with the new finder code. I suspect that the finder's new ParsePRRefs helper could be leveraged here as well, which would allow us to respect non-centralized workflows pr create in the same way we are respecting them in `gh pr view` and `gh pr status`
| if branchConfig.PushRemoteName != "" { | ||
| if r, err := rems.FindByName(branchConfig.PushRemoteName); err == nil { | ||
| prRefs.HeadRepo = r.Repo | ||
| } | ||
| } else if branchConfig.PushRemoteURL != nil { | ||
| if r, err := ghrepo.FromURL(branchConfig.PushRemoteURL); err == nil { | ||
| prRefs.HeadRepo = r | ||
| } | ||
| } else if remotePushDefault != "" { | ||
| if r, err := rems.FindByName(remotePushDefault); err == nil { | ||
| prRefs.HeadRepo = r.Repo | ||
| } | ||
| } else if branchConfig.RemoteName != "" { | ||
| // the branch merges from a remote specified by name | ||
| rem, _ := f.remotesFn() | ||
| if r, err := rem.FindByName(branchConfig.RemoteName); err == nil { | ||
| gitRemoteRepo = r | ||
| if r, err := rems.FindByName(branchConfig.RemoteName); err == nil { | ||
| prRefs.HeadRepo = r.Repo | ||
| } | ||
| } else if branchConfig.RemoteURL != nil { | ||
| if r, err := ghrepo.FromURL(branchConfig.RemoteURL); err == nil { | ||
| prRefs.HeadRepo = r | ||
| } | ||
| } | ||
|
|
||
| if gitRemoteRepo != nil { | ||
| if strings.HasPrefix(branchConfig.MergeRef, "refs/heads/") { | ||
| prHeadRef = strings.TrimPrefix(branchConfig.MergeRef, "refs/heads/") | ||
| } | ||
| // prepend `OWNER:` if this branch is pushed to a fork | ||
| // This is determined by: | ||
| // - The repo having a different owner | ||
| // - The repo having the same owner but a different name (private org fork) | ||
| // I suspect that the implementation of the second case may be broken in the face | ||
| // of a repo rename, where the remote hasn't been updated locally. This is a | ||
| // frequent issue in commands that use SmartBaseRepoFunc. It's not any worse than not | ||
| // supporting this case at all though. | ||
| sameOwner := strings.EqualFold(gitRemoteRepo.RepoOwner(), f.repo.RepoOwner()) | ||
| sameOwnerDifferentRepoName := sameOwner && !strings.EqualFold(gitRemoteRepo.RepoName(), f.repo.RepoName()) | ||
| if !sameOwner || sameOwnerDifferentRepoName { | ||
| prHeadRef = fmt.Sprintf("%s:%s", gitRemoteRepo.RepoOwner(), prHeadRef) | ||
| } | ||
| // The PR merges from a branch in the same repo as the base branch (usually the default branch) | ||
| if prRefs.HeadRepo == nil { | ||
| prRefs.HeadRepo = baseRefRepo |
There was a problem hiding this comment.
Looking for feedback on how to make this better... This is, at least, easy to understand this way 😅
|
Alright all, tests are 🟢! This blew up a bit, but I think it's trivialized the whole |
There was a problem hiding this comment.
Whew! I'll admit that this is a pretty big PR to review (~2 hours).
Aside from the automated tests passing, @jtmcg, can you confirm that the acceptance tests on this PR are also passing?
|
@jtmcg Do you think this should ship with some user-facing docs changes to describe the new behavior somewhere? Perhaps a help topic and a mention about the help topic in the relevant Probably should be a follow-up issue & PR because this PR is already so big, but I wanted to mention it somewhere. |
Yup, can confirm that I got them running today 👍 |
Yeah, that's a good idea, @BagToad. I definitely think we should call this out in the changelog, but also think a writeup would be helpful. Definitely a follow-up issue |
There was a problem hiding this comment.
After reviewing all of the changes, concerns, and questions from the previous review, I don't know what else needs to be addressed in order to ship this.
Solid work and thank you for diligence getting this shaped up, @jtmcg! ✨
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [cli/cli](https://github.com/cli/cli) | minor | `v2.65.0` -> `v2.66.1` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>cli/cli (cli/cli)</summary> ### [`v2.66.1`](https://github.com/cli/cli/releases/tag/v2.66.1): GitHub CLI 2.66.1 [Compare Source](cli/cli@v2.66.0...v2.66.1) #### Hotfix: `gh pr view` fails with provided URL This addresses a regression in `gh pr view` was reported in [#​10352](cli/cli#10352). This regression was due to a change in `v2.66.0` that no longer allowed `gh pr` subcommands to execute properly outside of a git repo. #### What's Changed - Hotfix: `gh pr view` fails with provided URL by [@​jtmcg](https://github.com/jtmcg) in cli/cli#10354 **Full Changelog**: cli/cli@v2.66.0...v2.66.1 ### [`v2.66.0`](https://github.com/cli/cli/releases/tag/v2.66.0): GitHub CLI 2.66.0 [Compare Source](cli/cli@v2.65.0...v2.66.0) #### `gh pr view` and `gh pr status` now respect common triangular workflow configurations Previously, `gh pr view` and `gh pr status` would fail for pull request's (MR) open in triangular workflows. This was due to `gh` being unable to identify the MR's corresponding remote and branch refs on GitHub. Now, `gh pr view` and `gh pr status` should successfully identify the MR's refs when the following common git configurations are used: - [`branch.<branchName>.pushremote`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtpushRemote) is set - [`remote.pushDefault`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remotepushDefault) is set Branch specific configuration, the former, supersedes repo specific configuration, the latter. Additionally, if the [`@{push}` revision syntax](https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-emltbranchnamegtpushemegemmasterpushemempushem) for git resolves for a branch, `gh pr view` and `gh pr status` should work regardless of additional config settings. For more information, see - cli/cli#9363 - cli/cli#9364 - cli/cli#9365 - cli/cli#9374 #### `gh secret list`, `gh secret set`, and `gh secret delete` now require repository selection when multiple `git` remotes are present Previously, `gh secret list`, `gh secret set`, and `gh secret delete` would determine which remote to target for interacting with GitHub Actions secrets. Remotes marked as default using `gh repo set-default` or through other `gh` commands had higher priority when figuring out which repository to interact with. This could have unexpected outcomes when using `gh secret` commands with forked repositories as the upstream repository would generally be selected. Now, `gh secret` commands require users to disambiguate which repository should be the target if multiple remotes are present and the `-R, --repo` flag is not provided. For more information, see cli/cli#4688 #### Extension update notices now notify once every 24 hours per extension and can be disabled Previously, the GitHub CLI would notify users about newer versions every time an extension was executed. This did not match GitHub CLI notices, which only notified users once every 24 hours and could be disabled through an environment variable. Now, extension update notices will behave similar to GitHub CLI notices. To disable extension update notices, set the `GH_NO_EXTENSION_UPDATE_NOTIFIER` environment variable. For more information, see cli/cli#9925 #### What's Changed ##### ✨ Features - Draft for discussing testing around extension update checking behavior by [@​andyfeller](https://github.com/andyfeller) in cli/cli#9985 - Make extension update check non-blocking by [@​andyfeller](https://github.com/andyfeller) in cli/cli#10239 - Ensure extension update notices only notify once within 24 hours, provide ability to disable all extension update notices by [@​andyfeller](https://github.com/andyfeller) in cli/cli#9934 - feat: make the extension upgrade fancier by [@​nobe4](https://github.com/nobe4) in cli/cli#10194 - fix: padded display by [@​nobe4](https://github.com/nobe4) in cli/cli#10216 - Update `gh attestation` attestation bundle fetching logic by [@​malancas](https://github.com/malancas) in cli/cli#10185 - Require repo disambiguation for secret commands by [@​williammartin](https://github.com/williammartin) in cli/cli#10209 - show error message for rerun workflow older than a month ago by [@​iamrajhans](https://github.com/iamrajhans) in cli/cli#10227 - Update `gh attestation verify` table output by [@​malancas](https://github.com/malancas) in cli/cli#10104 - Enable MSI building for Windows arm64 by [@​dennisameling](https://github.com/dennisameling) in cli/cli#10297 - feat: Add support for creating autolink references by [@​hoffm](https://github.com/hoffm) in cli/cli#10180 - Find MRs using `@{push}` by [@​Frederick888](https://github.com/Frederick888) in cli/cli#9208 - feat: Add support for viewing autolink references by [@​hoffm](https://github.com/hoffm) in cli/cli#10324 - Update `gh attestation` bundle fetching logic by [@​malancas](https://github.com/malancas) in cli/cli#10339 ##### 🐛 Fixes - gh gist delete: prompt for gist id by [@​danochoa](https://github.com/danochoa) in cli/cli#10154 - Better handling for waiting for codespaces to become ready by [@​cmbrose](https://github.com/cmbrose) in cli/cli#10198 - Fix: `gh gist view` and `gh gist edit` prompts with no TTY by [@​mateusmarquezini](https://github.com/mateusmarquezini) in cli/cli#10048 - Remove naked return values from `ReadBranchConfig` and `prSelectorForCurrentBranch` by [@​jtmcg](https://github.com/jtmcg) in cli/cli#10197 - Add job to deployment workflow to validate the tag name for a given release by [@​jtmcg](https://github.com/jtmcg) in cli/cli#10121 - \[gh run list] Stop progress indicator on failure from `--workflow` flag by [@​iamazeem](https://github.com/iamazeem) in cli/cli#10323 - Update deployment.yml by [@​andyfeller](https://github.com/andyfeller) in cli/cli#10340 ##### 📚 Docs & Chores - Add affected version heading to bug report issue form by [@​BagToad](https://github.com/BagToad) in cli/cli#10269 - chore: fix some comments by [@​petercover](https://github.com/petercover) in cli/cli#10296 - Update triage.md to reflect FR experiment outcome by [@​jtmcg](https://github.com/jtmcg) in cli/cli#10196 - Clear up --with-token fine grained PAT usage by [@​williammartin](https://github.com/williammartin) in cli/cli#10186 - Correct help documentation around template use in `gh issue create` by [@​andyfeller](https://github.com/andyfeller) in cli/cli#10208 - chore: fix some function names in comment by [@​zhuhaicity](https://github.com/zhuhaicity) in cli/cli#10225 - Tiny typo fix by [@​robmorgan](https://github.com/robmorgan) in cli/cli#10265 - add install instructions for Manjaro Linux by [@​AMS21](https://github.com/AMS21) in cli/cli#10236 - Update test to be compatible with latest Glamour v0.8.0 by [@​ottok](https://github.com/ottok) in cli/cli#10151 - Add more `gh attestation verify` integration tests by [@​malancas](https://github.com/malancas) in cli/cli#10102 #####Dependencies - Bump github.com/mattn/go-colorable from 0.1.13 to 0.1.14 by [@​dependabot](https://github.com/dependabot) in cli/cli#10215 - Bump github.com/sigstore/protobuf-specs from 0.3.2 to 0.3.3 by [@​dependabot](https://github.com/dependabot) in cli/cli#10214 - Bump github.com/gabriel-vasile/mimetype from 1.4.7 to 1.4.8 by [@​dependabot](https://github.com/dependabot) in cli/cli#10184 - Bump google.golang.org/protobuf from 1.36.2 to 1.36.3 by [@​dependabot](https://github.com/dependabot) in cli/cli#10250 - Bump golangci-linter and address failures to prepare for Go 1.24 strictness by [@​mikelolasagasti](https://github.com/mikelolasagasti) in cli/cli#10279 - Bump github.com/google/go-containerregistry from 0.20.2 to 0.20.3 by [@​dependabot](https://github.com/dependabot) in cli/cli#10257 - Bump actions/attest-build-provenance from 2.1.0 to 2.2.0 by [@​dependabot](https://github.com/dependabot) in cli/cli#10300 - Bump google.golang.org/protobuf from 1.36.3 to 1.36.4 by [@​dependabot](https://github.com/dependabot) in cli/cli#10306 - Upgrade sigstore-go to v0.7.0: fixes [#​10114](cli/cli#10114) formatting issue by [@​codysoyland](https://github.com/codysoyland) in cli/cli#10309 - Bump github.com/in-toto/attestation from 1.1.0 to 1.1.1 by [@​dependabot](https://github.com/dependabot) in cli/cli#10319 #### New Contributors Big thank you to our many new *and* longtime contributors making this release happen!! ❤️ ✨ - [@​zhuhaicity](https://github.com/zhuhaicity) made their first contribution in cli/cli#10225 - [@​danochoa](https://github.com/danochoa) made their first contribution in cli/cli#10154 - [@​robmorgan](https://github.com/robmorgan) made their first contribution in cli/cli#10265 - [@​iamrajhans](https://github.com/iamrajhans) made their first contribution in cli/cli#10227 - [@​AMS21](https://github.com/AMS21) made their first contribution in cli/cli#10236 - [@​petercover](https://github.com/petercover) made their first contribution in cli/cli#10296 - [@​ottok](https://github.com/ottok) made their first contribution in cli/cli#10151 - [@​dennisameling](https://github.com/dennisameling) made their first contribution in cli/cli#10297 - [@​iamazeem](https://github.com/iamazeem) made their first contribution in cli/cli#10323 - [@​Frederick888](https://github.com/Frederick888) made their first contribution in cli/cli#9208 **Full Changelog**: cli/cli@v2.65.0...v2.66.0 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNDMuMCIsInVwZGF0ZWRJblZlciI6IjM5LjE0Ni40IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
0179381efFind PRs using @{push}7fc35fd47Only find PRs w/ branch.<name>.merge if push.default = upstream/tracking4254818dbFind push remote using branch.<name>.pushRemote and remote.pushDefault2d1e4d625Add base gh pr view acceptance tests for changeseb16a75abExpand with gh pr status8bb2879b8Reflect coverage for view and status subcommandsbe250b3d3Add renamed acceptance tests0006091d7Fix up intra-org fork test setupThis fixes things like
gh pr viewin apush.default = simple / current+ upstream pointing to target branch.It does not fix the issues with
gh pr create.Related to: #575.