cli: PR checkout: fully-qualified git refs unexpectedly received from the API
Describe the bug
It appears that having a remote pointer to the source of my fork (with any name) is making checking out a specific PR fail. Other PRs work so perhaps there is something strange about this branch, but I cannot figure out what.
❯ gh --version gh version 1.5.0 (2021-01-21) https://github.com/cli/cli/releases/tag/v1.5.0
Steps to reproduce the behavior
gh repo clone https://github.com/billwert/performance cd performance gh checkout 1654
Expected vs actual behavior
The PR checkout should succeed.
Logs
D:\source [12:14]
❯ gh repo clone https://github.com/billwert/performance performance5
Cloning into 'performance5'...
remote: Enumerating objects: 80, done.
remote: Counting objects: 100% (80/80), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 28586 (delta 41), reused 52 (delta 27), pack-reused 28506
Receiving objects: 100% (28586/28586), 13.70 MiB | 26.32 MiB/s, done.
Resolving deltas: 100% (17376/17376), done.
Updating files: 100% (28225/28225), done.
Updating upstream
remote: Enumerating objects: 130, done.
remote: Counting objects: 100% (130/130), done.
remote: Compressing objects: 100% (35/35), done.
Receiving objects: 57% (88/154)l 154 (delta 110), reused 111 (delta 95), pack-reused 24
Receiving objects: 100% (154/154), 23.17 KiB | 7.72 MiB/s, done.
Resolving deltas: 100% (110/110), completed with 31 local objects.
From https://github.com/dotnet/performance
* [new branch] 2.2 -> upstream/2.2
* [new branch] adamsitnik-reorder-channels -> upstream/adamsitnik-reorder-channels
* [new branch] darc-master-0275f095-330f-46bf-b4dd-74d66423f356 -> upstream/darc-master-0275f095-330f-46bf-b4dd-74d66423f356
* [new branch] darc-master-db2ec933-6e3c-47bb-a131-f55b461d2f3a -> upstream/darc-master-db2ec933-6e3c-47bb-a131-f55b461d2f3a
* [new branch] darc-release/3.1.4xx-15b83e83-b5a6-4303-8057-877413bd7efa -> upstream/darc-release/3.1.4xx-15b83e83-b5a6-4303-8057-877413bd7efa
* [new branch] feed-update-master -> upstream/feed-update-master
* [new branch] feed-update-release/3.1.1xx -> upstream/feed-update-release/3.1.1xx
* [new branch] feed-update-release/3.1.4xx -> upstream/feed-update-release/3.1.4xx
* [new branch] feed-update-release/5.0.1xx -> upstream/feed-update-release/5.0.1xx
* [new branch] feed-update-release/5.0.2xx -> upstream/feed-update-release/5.0.2xx
* [new branch] master -> upstream/master
* [new branch] release/3.1.1xx -> upstream/release/3.1.1xx
* [new branch] release/3.1.2xx -> upstream/release/3.1.2xx
* [new branch] release/3.1.3xx -> upstream/release/3.1.3xx
* [new branch] release/3.1.4xx -> upstream/release/3.1.4xx
* [new branch] release/5.0.1xx -> upstream/release/5.0.1xx
* [new branch] release/5.0.2xx -> upstream/release/5.0.2xx
D:\source [12:14]
❯ cd performance
D:\source\performance master ≣ ~1 -0 ! [12:14]
❯ cd ..
D:\source [12:14]
❯ cd performance5
D:\source\performance5 master ≣ [12:14]
❯ gh pr checkout 1654
? Which should be the base repository (used for e.g. querying issues) for this directory? dotnet/performance
**fatal: couldn't find remote ref refs/heads/refs/heads/feed-update-master**
exit status 128
⨯ D:\source\performance5 master ≣ [12:15]
❯ git remote -v show
origin https://github.com/billwert/performance.git (fetch)
origin https://github.com/billwert/performance.git (push)
upstream https://github.com/dotnet/performance.git (fetch)
upstream https://github.com/dotnet/performance.git (push)
D:\source\performance5 master ≣ [12:15]
❯
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 16 (11 by maintainers)
I think I’m seeing something very similar for https://github.com/dotnet/msbuild, but (confusingly) only for some PRs:
Thank you for reporting! This looks like it might be an API problem and is not caused by your git remote configuration, which seems perfectly in order.
Specifically, the GraphQL fields
headRefName
andbaseRefName
on a PullRequest return values prefixed byrefs/heads/
for some pull requests in this repo, but not for others.Please allow us a bit more time to look into this. 🙇