Repository navigation
Fails to find issues and PRs correctly for active forks #867
Description
Activity
This was discussed at length in #350. The verdict at the time was that we will keep defaulting to the parent repo, since most people use their forks as means of sending patches only, but usually want to query issues/PRs in the canonical repo.
The workaround for now is to use the
-Rflag to explicitly specify the repo you want to query:gh pr checkout 93 -R westonruter/syntax-highlighting-code-block.However, I do understand your use case. Now that we have a config mechanism, I wonder whether it would be worthwhile to add a per-repository config such as
gh config --local base_remote originso that people could explicitly opt-out of this behavior for their active forks.I'm going to re-classify this as a feature while we wait for more feedback.
Reacted by Vladimir JimenezReacted by Christopher Little-SavageI consider this a bug.
I have the following repo cloned locally https://github.com/SuperSandro2000/supersandro2000.github.io/
and want to checkout SuperSandro2000/supersandro.de#2 which fails. This does not really make sense cause the PR is against my fork and not the base repo.I am also experiencing issues with this, as a contributor to a "friendly fork" project that merges from the parent repo occasionally but will never be merged in (https://github.com/adafruit/circuitpython). It's useful to know about the -R workaround, but since I need to use it for every command, a config option would definitely be nicer.
Reacted by Dan Halbert and ElKowarA per-repo config option for this would definitely be the way to go. At least mentioning the -R option when running
gh pr listwould be nice, something along the lines ofshowing PRs for parent repository. To see PRs on the fork <username>/<reponame>, specify '-R <username>/<reponame>'Reacted by Joan Milev, ariealerr, Lucian Copeland and Vladimir Jimenez
Describe the bug
When I clone a repo that is an active fork (one that has no intentions of being merged back in), any
ghcommand will call commands relative to the original repo.For example, I am working on westonruter/syntax-highlighting-code-block, which is a fork and has completely diverged from the original project. Any
ghcommand here will try hit the original repo (mkaz/code-syntax-block) this repo was forked from.Steps to reproduce the behavior
This happens because
mkaz/code-syntax-blockdoes not have a PR 93 butwestonruter/syntax-highlighting-code-blockdoes, so this command should be valid.Expected vs actual behavior
I expect that if I am cloning a forked repository, any issues or pull requests I list/create via
ghshould take that forked repository as the target and not the original repository.