What you needed was to use the options -h (head, ie. the feature branch) and -b (base, ie the upstream master) eg.

    git pull-request \
      -m "I added an awesome feature"\
      -b baserepo:master\
      -h myfork:feature-branch

The GitHub web interface defaults to the PR-to-upstream behavior though, so this is at least an inconsistency; I would argue it is a bug.

You could submit a pull request to hub to fix it!

Perhaps not using hub to do so, though.

hub works just fine to create a PR, some lack of RTFM is at play.

So, I never trust users to give me advice on features to add.

But I always believe them when they say something is difficult or confusing. Research should not be required to make a good CLI do what you want, provided you understand what you want.

Might like http://blog.codinghorror.com/listen-to-your-community-but-do...

I believe will always default to sending the PR to the remote named origin. If you have the original repo listed as origin and your repo as a remote with your username, you get the expected behaviour. I think the issue here is that hub has no explicit knowledge of the ancestry of the repo so unless it fetches this from the GH API, I think it's doing the only logical thing.

It sure would be nice to have `--dry-run --verbose` to see exactly what it's going to do.