If the user is currently on the "feature" branch that is pushed to their
fork, when they do `hub browse -- issues` it should open issues of the
main (canonical) repository, not that of the fork.
When a user would do `hub browse` on the master branch and they had a
fork, the hub would open the browser with their fork instead of the
upstream project. This is surprising and unwanted, so I've added an
exception for this case.
Fixes#474
In hub lingo, "origin remote" is the remote pointing to the canonical
GitHub project, i.e. where pull requests should be sent. "Remote branch"
is where hub guesses the user has pushed their changes from the current
local branch.
The origin remote can now be called "upstream", "github", or "origin",
in that order of precedence.
The `browse`, `compare`, and especially `pull-request` commands need to
know the remote branch. Previously we relied on git upstream
configuration, but that wasn't enough. This behavior is now only kept if
git "push.default" is set to "upstream" or "tracking".
For "push.default" values "current", "simple" (git 2.0 default), or
"matching" (git 1.x default), we can safely assume that the user
probably pushes to the same-named branches on some remote, and we ignore
upstream configuration.
To find the remote where the user pushed their changes, we search for
the same-named branch on:
1. the remote which points to a GitHub project owned by the current user;
2. "origin", "github", and "upstream" remotes.
When a match is found, it is assumed that the user pushed there and it
is taken as the implicit pull-request head.
Fixes#158, fixes#360, fixes#381
if your branch name contains some characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.
an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.