Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't require GitHub repo to be origin remote #227

Closed
parkr opened this issue Oct 12, 2014 · 12 comments
Closed

Don't require GitHub repo to be origin remote #227

parkr opened this issue Oct 12, 2014 · 12 comments

Comments

@parkr
Copy link

parkr commented Oct 12, 2014

Hey, I have a repo I backup to GitHub so I have the github repo setup as the gh remote. It would be great if gh looped through all the remotes and found the one whose host matched the GITHUB_URL and used that for the relevant commands. Thoughts?

@owenthereal
Copy link
Owner

What gh commands are you trying to use this with?

@parkr
Copy link
Author

parkr commented Oct 15, 2014

gh browse, gh issue [create] both fail.

@owenthereal
Copy link
Owner

gh browse and gh issue only work with the origin remote. Do you mean gh takes an optional GitHub remote for the operation? Say gh browse gh where gh is pointing to another GitHub remote.

@parkr
Copy link
Author

parkr commented Oct 16, 2014

That's certainly an option. What I'd like is for gh to iterate through all the remotes and choose the best one. In the case that my remotes only contain one github.com remote, that choice should be easy as pie.

@deiga
Copy link

deiga commented Oct 17, 2014

@parkr That sounds like an really expensive operation and way too error-prone. If your repo contains multiple github.com urls how do you think it should decide which is the one to use?

@parkr
Copy link
Author

parkr commented Oct 17, 2014

Based on who's logged in, I'd say. gh knows I'm logged in, so can choose git@github.com:parkr remotes. At the very least, giving me a way to specify a non-origin remote seems pretty reasonable. Ideally gh would know what repo to open and would open it.

@deiga
Copy link

deiga commented Oct 17, 2014

@parkr what if you have write access to a remote which is not under your name? and you happen to have a fork of the same repo under your name?

@parkr
Copy link
Author

parkr commented Oct 17, 2014

@parkr what if you have write access to a remote which is not under your name? and you happen to have a fork of the same repo under your name?

hub always preferred the canonical repo. It would find the one under your username, check to see if it is a fork, and, if so then open up the canonical repo, otherwise open up my repo.

@cw-peter
Copy link

I'd like a --remote flag for gh issue as I'm often working with forks of the canonical repo which contains the issues

@flying-sheep
Copy link

yeah, indeed. same for gh pull-request.

for me, the canonical repo is seldomly origin, that’s my fork, unless i’m a contributor! i chose upstream as a personal convention, which coincidentally matches what other people do

@parkr parkr closed this as completed Jun 15, 2015
@flying-sheep
Copy link

so, what names are supported now? gh? upstream? hub?

@owenthereal
Copy link
Owner

@flying-sheep The origin names lookup order is upstream, github and origin. Also gh has been merged into hub. Please move onto hub for further feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants