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.
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.
Just a note, you can simplify your workflow even further by using `hub pull-request` . If your PR consists of a single commit, it'll even pre-populate the PR description for you (if not, it helpfully lists the commits included in the PR in the comments of the PR/commit message).
If you want to review the PR before submitting it you can also do `hub compare my-contrib` and it will open up the comparison in your browser. One more click to turn it into a PR.
I know I don’t like doing it that way. I use `git` (actually, I have `alias g=git`, so I actually write `g`) directly for most things, only pulling out `hub` for GitHub-specific things.
I'm quite fond of of Ingy's git-hub command, https://github.com/ingydotnet/git-hub, which also gives you most of Hub's features, along with much, much more. E.g., the the ability to manage things like a repo's collaborators, issues, etc. from the command line. And it's a normal git extension command, so you run it as `git hub clone foo/bar` or `git hub issue-new` or `git hub pr-list` which feels like a better point of integration.
Edit: And per some concerns elsewhere in the comments, there's also a --dryrun parameter to ensure that it's going to do what you want it to do. ;)
22 comments
[ 7.7 ms ] story [ 123 ms ] threadIt sent the PR from my branch on my fork to master on my fork. Obviously I wished to PR against the original thing I forked from.
I just stick to the web interface now.
Perhaps not using hub to do so, though.
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.
World domination feels imminent.
Edit: And per some concerns elsewhere in the comments, there's also a --dryrun parameter to ensure that it's going to do what you want it to do. ;)
The release notes for version 2.2.0 mention their [cucumber specs](https://github.com/github/hub/tree/master/features), which look like a good example of using BDD in a full project.
And then I wandered off and got distracted by a UTF-8 problem in the Hebrew localization of Test::BDD::Cucumber.
[0] http://nodegh.io/