Repository navigation
gh repo view fails on forked repo #9132
Description
Activity
Hey @Shion1305, thanks for creating this and sorry four your trouble. For forked repos we expect a default to be set so that we know whether to work with the upstream or the fork. For example, most of the time when running
pr createyou would expect it to be created against the upstream.However, your repo seems to be in an unusual state since it appears you only have one remote. How did you fork this repo and clone it onto your machine? Did you do anything with the remotes after cloning?
@williammartin Thanks for checking this issue!
I have forked the repo byforkbutton on the repository page, and cloned the folked repo bygit clone ~
I haven't done any operation with git after that, so this is strange.Right, I can explain then. Since you didn't use
gh repo fork --clone, orgh repo clone,ghis recognising that it is working on a fork because when working with a repository, we resolve the network for it, which includes the parents of any remotes. If there is more than one remote (and no default), we requiregh repo set-defaultto make sure thatghis interacting with the correct repository.If you use
gh repo clone, we set the default to the upstream:➜ gh repo clone github-readme-stats Cloning into 'github-readme-stats'... remote: Enumerating objects: 7110, done. remote: Counting objects: 100% (1112/1112), done. remote: Compressing objects: 100% (60/60), done. remote: Total 7110 (delta 1084), reused 1058 (delta 1052), pack-reused 5998 Receiving objects: 100% (7110/7110), 3.56 MiB | 3.44 MiB/s, done. Resolving deltas: 100% (4977/4977), done. From https://github.com/anuraghazra/github-readme-stats * [new branch] master -> upstream/master * [new tag] v1.0.0 -> v1.0.0 ! Repository anuraghazra/github-readme-stats set as the default repository. To learn more about the default repository, run: gh repo set-default --helpSo you will need to run
gh repo set-defaultand choose the remote that you want API requests to work against i.e.➜ gh repo set-default --help This command sets the default remote repository to use when querying the GitHub API for the locally cloned repository. gh uses the default repository for things like: - viewing and creating pull requests - viewing and creating issues - viewing and creating releases - working with GitHub Actions - adding repository and environment secretsTypically the upstream is the right choice. Functionally what this does is put an entry in your
.git/configcalledgh-resolved. In the case ofgh repo cloneit sets the value tobaseon the upstream remote:➜ github-readme-stats git:(master) cat .git/config ... [remote "origin"] url = https://github.com/williammartin/github-readme-stats.git fetch = +refs/heads/*:refs/remotes/origin/* [remote "upstream"] url = https://github.com/anuraghazra/github-readme-stats.git fetch = +refs/heads/*:refs/remotes/upstream/* gh-resolved = baseAnd in your case where you only have one remote, it sets the value to the location of the upstream repo:
➜ github-readme-stats git:(master) cat .git/config ... [remote "origin"] url = https://github.com/williammartin/github-readme-stats.git fetch = +refs/heads/*:refs/remotes/origin/* gh-resolved = anuraghazra/github-readme-statsOne improvement I can see is that when we do the automatic defaulting we include "To learn more about the default repository, run: gh repo set-default --help", which would probably be useful to include in your case as well.
Hope this helps!
- changed the title
[-]`gh repo view` fails on folked repo[/-][+]`gh repo view` fails on forked repo[/+]on May 28, 2024 I stumbled upon this issue when researching a different issue: After moving repo to a new org, pr create adds a new remote named fork every time.
About the current issue, do I have it right that the overall improvement being considered is the setting of the only remote (in the case of
git cloneclones) as the default repository, instead of prompting the user to manually set withgh repo set-default?That sounds like a sensible change to me, but I'm also a bit curious about why this wasn't considered so far. Are there any consequences of automatically setting it? 🤔
About the current issue, do I have it right that the overall improvement being considered is the setting of the only remote (in the case of git clone clones) as the default repository, instead of prompting the user to manually set with gh repo set-default?
No, I'm not proposing a functional change here just a documentation one. There's a very real chance that even if you forked and cloned outside of
gh, you still intend to work with the upstream repo, and I think it's just better to force the user to make a decision up front.I am open to being convinced otherwise though, I was not on the team when the concept of
defaultwas introduced so I don't have any particularly strong feelings except a bit of Chesterton's Fence related anxiety. 😅Also relevant issue that I came across today which was surprising behaviour to me: #9152
Labelling this
help wantedwith the action item being an update to ensure:One improvement I can see is that when we do the automatic defaulting we include "To learn more about the default repository, run: gh repo set-default --help", which would probably be useful to include in your case as well.
Is addressed.
Describe the bug
I haven't figured out the reason, but I have failed to call
gh repo viewon forked repo.Steps to reproduce the behavior
gh repo viewExpected vs actual behavior
It should show info of forked repo.