Hub Git Wrapper(github.com)
github.com
Hub Git Wrapper
https://github.com/github/hub
22 comments
Thanks to hub the friction to contributing is much lower for me. That's how I contribute back to projects on github:
hub clone user/repo
cd repo
git checkout -b my-contrib
# ... fix fix fix ...
hub fork
git push -u zimbatm my-contrib
hub browse # Opens browser on my fork
# Create PR with comment in browserJust 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.
Node GH [0] seems to do a few things better including the plugin architecture allowing integration with JIRA and others.
[0] http://nodegh.io/
[0] http://nodegh.io/
I once tried to PR from hub.
It 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.
It 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.
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-branchThe 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.
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.
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.
It sure would be nice to have `--dry-run --verbose` to see exactly what it's going to do.
I've been using Hub forever. It's a lovely bit of improvement over raw git, at least for Github-based projects.
hub pull-request is my favorite feature. It cuts the actions down from many mouse clicks to one command in terminal.
> hub is best aliased as git, so you can type `$ git <command>` in the shell and get all the usual hub features.
World domination feels imminent.
World domination feels imminent.
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.
In my experience it slows the `git` command down quite a bit and therefore my prompt. It's not too difficult to type hub instead :/
I can see Linus Torvalds doing a table flip over this part. (╯°□°）╯︵ ┻━┻
Yes, sure smells like a case of embrace & extend.
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. ;)