Hub: "browse" will not open forked project page when upstream remote is present

[sfdye]

If the upstream remote is present, the "browse" command will open the upstream repo page instead of the forked one. Is this a feature or just wrong behavior?

[mislav]

Sorry for the confusion. hub browse picked the "upstream" remote to navigate to as "main" project that it guesses you wanted to browse to. It guessed wrong, since you wanted to browse to your fork. Some people, however, want to browse to the upstream project. How do we make a default that satisfies everybody's expectations?

[sfdye]

I see, if the purpose of opening the page is to create a pull request, both will do the trick. But for navigation, I can go easily from forked page to upstream page, but not vice versa. What do you think?

[sfdye]

Or we can introduce a new option --f which will open for fork, and open for upstream by default. I will be happy to throw a PR for this.

[dreua]

@sfdye You can easily go to your fork by clicking the "Fork" button on the main project. (This is not intuitive but a good shortcut once you know it. Btw, I had to use Google to learn this.)

[sfdye]

@dreua I see, but it requires two additional clicks.

[dreua]

@sfdye Sorry, I think my previous comment was misleading and maybe off topic: I just wanted to point you to a shortcut in navigating GitHub that I find useful and I thought you were not aware of it. I was not arguing against your proposal.

[sfdye]

@dreua I see 😄

[tammersaleh]

this bit me today (so I renamed upstream to something else). I expected it to open my personal fork. I'd like to see the -f option so it's explicit.

[sfdye]

Looks like the reason is because push.default=simple

https://github.com/github/hub/blob/master/features/browse.feature#L73-L79

[danielhoherd]

It seems to me this would be best solved with a default behavior and a flag to override it. EG:

$ hub browse --remote=origin  # opens remote named origin
$ hub browse  # opens upstream repo, same as: hub browse --remote=upstream

Or maybe...

$ hub browse --refspec=origin/master

An alternative behavior could be to have a hub verb that shows browseable URLs for all locally discoverable refspecs, similar to git branch -a

$ hub urls
https://github.com/github/hub/tree/master
$ hub urls -a
https://github.com/github/hub/tree/master
https://github.com/github/hub/tree/format-releases
https://github.com/github/hub/tree/gh-pages
https://github.com/octocat/hub/tree/master
https://github.com/octocat/hub/tree/implement-url-verb-for-hub-command

[mislav]

Closing this in favor of the per-command --remote=REMOTE configuration idea that's on our roadmap https://github.com/github/hub/issues/1973#issuecomment-450247889

See also https://github.com/github/hub/issues/1706#issuecomment-461233147 for the explanation of why the design of hub browse is not the greatest and my thoughts on the future plans to deprecate it in favor of a new command