I've tried both, I prefer `hub`. For those thinking of switching, a couple of things to consider (also feedback for the `gh` team):
1. `gh` will error out if it encounters an escape sequence it doesn't understand. E.g., I have `⌥backspace` delete the previous word, and I hit it frequently without thinking about it. This works in most TUIs, but instantly interrupts `gh` and I have to start over.
2. There's no way to use your `$EDITOR` to edit the pull request title. This is how `hub` works by default, and personally I find it perfect and natural.
3. There aren't very many flags, so it forces you to manually interact with the TUI. For example, most of the time I'm doing a quick PR that doesn't need a body, and that I don't need to preview in the browser. I can't pass flags to `gh` to skip these steps, so I have to manually interact with the TUI to get past them every time.
In general, I get the impression that `gh` is designed for people who aren't comfortable with command-line conventions, e.g., using your `$EDITOR`, and setting options via flags. Nothing wrong with that, but if you are comfortable with (and prefer) those conventions, then it's a good idea to stick with `hub`.
Further to the $EDITOR thing, I hope people don't actually use `-b "entire contents of issue right here on the command line"`. Small doesn't necessarily mean content-free, but I find the good issues tend to have a bunch of information and investigation in them. That's a way you can contribute to open source; otherwise, you're just creating a poor quality support ticket.
It's not like `hub` doesn't have the `-m` flag, but opening up EDITOR by default, without even asking "press e for nano", helps. In the same way issue templates tend to. It's a nudge in the right direction.
For the record, I’ve used `hub` for years and never aliased it to `git`, and I’ve never encountered any problems. I just use `git` for Git features and `hub` for GitHub features.
Interestingly, on gitlab.com, you can trigger some options (create Merge Request, skip the CI pipeline for your push or set CI variables) straight through git push --push-option
There are a few common instances where I'm in the terminal doing git stuff and have to break the "flow" by switching to the browser to go click some buttons.
Creating a new repo is one; creating a pull request is another.
That said, I like to leave the vendor lock-in out of my sacred terminal as much as possible, so I might prefer to just click the buttons in the end.
> leave the vendor lock-in out of my sacred terminal
Exactly! I don't mind doing vendor-specific things whilst interacting with their websites, because my brain jumps to the right "mode" for each. This is not so within the terminal, though.
The phrase I've quoted is a brilliant expression of something I've never quite realized. Thank you.
I don't think so, I have custom aliases I add to every machine to do some of these things, so this is a welcome tool. Working with issues is something I was completely missing as well
It seems to do pretty much the same things, except it works a little more separate from git itself whereas hub is designed to shim on top of git.
edit: nvm answered my own question https://github.com/cli/cli/blob/master/docs/gh-vs-hub.md . I don't know, I'm not convinced spinning out a new CLI was the right move. hub is actually really nice.