Skip to content

gh issue list: looks at original repo not current origin for issues #439

Closed
Closed
gh issue list: looks at original repo not current origin for issues#439

Description

@graeme-winter
graeme-winter
opened on Feb 14, 2020

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

  1. tierninho commented on Feb 14, 2020

    @tierninho
    tierninho
    on Feb 14, 2020
    Contributor

    @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.

  2. vilmibm commented on Feb 14, 2020

    @vilmibm
    vilmibm
    on Feb 14, 2020
    Contributor

    It's intentional and for now the workaround is to use the -R option (eg gh 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.

  3. graeme-winter commented on Feb 14, 2020

    @graeme-winter
    graeme-winter
    on Feb 14, 2020
    Author

    Thanks for the feedback - I had not registered that the -R option would do this for me.

    Detecting the remote arrangement would be neat, but the work around is helpful here.

  4. billygriffin commented on Mar 3, 2020

    @billygriffin
    billygriffin
    on Mar 3, 2020
    Contributor

    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.

  5. billygriffin
    closed this as completedon Mar 3, 2020
  6. Stonre
    added a commit that references this issue on Jul 21, 2025

    Expand additional $refs for structured_output (cli#439)

    730f01e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions