
gh – GitHub's new CLI - flipchart
https://johnpapa.net/try-githubs-new-cli-gh/
======
carlosdp
How is this different from `hub`?
[https://github.com/github/hub](https://github.com/github/hub)

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](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.

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

~~~
cormacrelf
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.

------
cbarrick
I hope this doesn't mean hub is going away.

For those that don't know, hub is a command that extends git with GitHub
specific features. It has most of the features of gh AFAICT.

Unlike gh, hub a drop-in replacement for git, so you're expected to `alias
git=hub`.

[https://github.com/github/hub](https://github.com/github/hub)

Edit: [https://github.com/cli/cli/blob/master/docs/gh-vs-
hub.md](https://github.com/cli/cli/blob/master/docs/gh-vs-hub.md)

~~~
robenkleene
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.

------
kl4m
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_

[https://docs.gitlab.com/ee/user/project/push_options.html](https://docs.gitlab.com/ee/user/project/push_options.html)

~~~
oweiler
I use this to open a new merge request on push.

------
ykevinator
Is this a solution looking for a problem?

~~~
montroser
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.

~~~
bluenose69
> 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.

