Repository navigation
gh issue list: looks at original repo not current origin for issues #439
Description
Describe the bug
A clear and concise description of what the bug is. Include version by typing gh --version.
Grey-Area dxtbx :( [master] $ gh --version
gh version 0.5.5 (2020-02-13)
https://github.com/cli/cli/releases/tag/v0.5.5
Grey-Area dxtbx :( [master] $ git remote -v
origin [email protected]:cctbx/dxtbx (fetch)
origin [email protected]:cctbx/dxtbx (push)
upstream [email protected]:dials/dxtbx (fetch)
upstream [email protected]:dials/dxtbx (push)
It would be better if it could check origin for issues in place of upstream (here we have upstream configured differently as a release source not development base)
Grey-Area dxtbx :) [master] $ gh issue list
Issues for dials/dxtbx
the 'dials/dxtbx' repository has disabled issues
Steps to reproduce the behavior
git clone [email protected]:cctbx/dxtbx
gh issue list
Expected vs actual behavior
I expect it to give this issue list:
https://github.com/cctbx/dxtbx/issues
Logs
Done so above - appreciate the command-line tool, this will help with my usual work flow, thank you
Activity
tierninho commentedon Feb 14, 2020
@graeme-winter thanks for filing this. I was able to reproduce this. I am unsure if this was intentional as forked repos at the time of creation have Issues disabled. It is just a coincidence that the upstream repo had its Issues disabled.
I will leave this open for other members of the team to weigh in.
vilmibm commentedon Feb 14, 2020
It's intentional and for now the workaround is to use the
-Roption (eggh issue list -Rcctbx/dxtbx).The better fix we have planned is to detect this remote arrangement and ask if you'd like us to default to parent or fork when querying issues and PRs and remembering that per-repo.
graeme-winter commentedon Feb 14, 2020
Thanks for the feedback - I had not registered that the
-Roption would do this for me.Detecting the remote arrangement would be neat, but the work around is helpful here.
billygriffin commentedon Mar 3, 2020
Thanks for the issue @graeme-winter. I laid out our current thinking in #350 (comment), and unfortunately the tradeoff with our chosen defaults (at least for now) is cases like this one, it won't pick up the correct repo without you using -R to specify it. I know that's suboptimal and these are tough responses to write, but our general philosophy is opinionated defaults with simple fallbacks, and I think this fits that criteria. Thanks again for sharing how it was falling down for you, and we're not at all opposed to revisiting if we see that this is a more widely used pattern than our current working assumption.
Expand additional $refs for structured_output (cli#439)