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.
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`.