Hacker News Reader

Comment by geerlingguy | Hacker News Reader

I've been using Hub[1] (though not aliased to `git`) for years now, and it's PR management capabilities have been invaluable working on larger projects. Hopefully GitHub CLI is as stable and reliable!

It looks like the main features I use from Hub are already well-supported in the GitHub CLI, and it looks like whether or not Hub will still be maintained is an open question[2].

Edit: Just noting that `brew install github` doesn't work, it's actually `brew install github/gh/gh` — that's a new format for brew packages I haven't seen before.

[1] https://github.com/github/hub

[2] https://github.com/github/hub/issues/2470

View on HN

One thing I really hope they keep from Hub is the way it creates pull requests, namely by opening $EDITOR and using the first line as the PR title and the rest as description, ie. exactly the same mechansim as git uses for "git commit".

Needing to navigate a menu to set title and description as it seems to show in the screenshots seems like completely unnessecary friction.

For the title, it prompts, then for the description, it lets you either enter an editor of your choice.

The thing I like most about it in a little use today, though, is when it goes to create the PR, it lets you choose to create it directly, or open a 'preview' of the PR in the browser. This is nice for creating Draft PRs which you're still working on and should not yet be merged (since, right now, there's no way to create a PR then put it back into 'Draft' state).

> first line as the PR title and the rest as description

> exactly the same mechanism as git uses for "git commit"

That's not how git commit works. git commit opens $EDITOR and makes a list of lines (sans commented-out lines) from that. The first line being a title is only convention, whereas in a github PR it's a formal element of the system.

It's not really just convention. Git commit messages map directly to emails for workflows that don't use web UIs like GitHub, with the first line being the subject and the rest being the email body. That's how you mail a commit to someone else for them to review it or incorporate it into their local repo.

If you don't format your commit messages properly then they'll just be a sloppy mess in any email-based workflow (like what Linux uses).

And the first line is the only line that's displayed in contexts like `git log`, so it truly is the commit summary even if you aren't emailing commits.

That's still just a convention :-) But you'll find that most of the things humans do are. Everything is a social construct.

If you're going to define your words in such a way that what you're saying is meaningless, why bother even saying anything at all?

It's a bit more than just a convention, since `git log` has lots of formatting options that rely on that first line being the title/subject.

I stopped using hub to create PRs because it wouldn't fill in the issue template. I don't know if that's ever been fixed. Instead I used it to "compare" my changes, which opens the page in the browser with the "create pull request" button available where I go through the in-browser PR flow.

It definitely uses the issue template nowadays, if there is one. If there isn't, and the PR is one commit, it will reuse the commit message. If it's multiple commits, it'll give you a commented out list of every commit message, which I generally then give a title to and munge down into a description.

I would be surprised if it didn't work that way. That's the way PRs work on their website too.

The main developer of this at Github wrote a blogpost about the design decisions behind CLI, and how it fits/replaces Hub. [0]

[0] https://mislav.net/2020/01/github-cli/

Hi! I'm on the team building GitHub CLI. We're definitely eager for your feedback on what things feel like they're missing, and especially if something is broken or doesn't feel stable or reliable. Feel free to open an issue if there's anything that stands out.

The different homebrew installation you referred to is because `gh` isn't part of homebrew/core yet as it's very new. So we'll be adding it in the coming months, but for now that's just a way for us to maintain our own tap and still provide an easy install/upgrade path.

I use "hub browse" a lot. It's a really quick way to open a local directory's Github repo.

Unfortunately, it's quite limited. No way to open a specific file, for example, or jump to a specific branch other than the current one.

I'd love to have something like "gh open".

It's on our roadmap! https://github.com/cli/cli/issues/217

>`gh` isn't part of homebrew/core yet as it's very new. So we'll be adding it in the coming months

It's been part of homebrew/core for something like two weeks: https://github.com/Homebrew/homebrew-core/blob/master/Formul...

Thanks for the shout! That was a community contribution and I totally missed it! It was an outdated version, but should now be updated to the latest 0.5.4. Really appreciate you sharing this. :)

Congratulations on shipping!

Just installed it on fedora using dnf and tried my usual git commands using hub instead. So far so good. I haven't tried any hub specific features yet though.

It is nice that I can just dnf install hub

Thanks! I'm definitely curious what you think when you start venturing into creating and checking out PRs in particular, and how we're managing the `pr status` and `issue status` commands in terms of what's shown vs. what you expect or would like to see to get the most relevant context.

We're definitely eager for your feedback on what things feel like they're missing

Uploading releases please!

Huh, I'm confused that this announcement doesn't even mention the existing `hub` tool, which is also in the `github` organization... this is a new rewrite replacement for it?

I agree the main thing I use `hub` for is PR management. Specifically creating PRs.

It had seemed to me that hub was somewhat undermaintained lately, so I guess I'm glad they've released a new tool which appears to maybe cover the same things, which perhaps will be better maintained.... but confused that they are releasing a new tool which does the same thing as an already existing tool also from github...

Hub was created by Chris Wanstrath, one of the original GitHub founders, so it's not surprising there's no reference to it. There's a damnatio memoriae of GitHub's founders and founding story because of certain subcultures that were fostered there by the people they chose to hire.

So dumb, these are the people who literally created GitHub, show them the damn respect they deserve. `hub` (a tool I use to this day) is clearly the predecessor to this official CLI.

No disrespect to hub whatsoever, and it helped inspire much of how we've thought about `gh`. We're fans of hub too and just decided to take this in a bit different direction.

Could you elaborate, or at least spill the tea?

Circa 2014 there was a big blowup of allegations centering around then-CEO Tom Preston-Werner and his wife (not an employee, but worked at the office). Tom resigned as a result.

I don't know why Wanstrath would be excised from collective history though - he was founding CEO (2008-2012) and stepped in again after Tom (2014-2017). Wikipedia says he's now a technical fellow at MS since the acquisition.

> Edit: Just noting that `brew install github` doesn't work, it's actually `brew install github/gh/gh` — that's a new format for brew packages I haven't seen before.

It's not new, but what you've perhaps seen is more like `brew install OJFord/formulae/gh` - 'most' (I haven't surveyed, but in my experience) people call the repo `homebrew-formulae`, `homebrew-` gets stripped, leaving:

> `<GH user>/<repo name less 'homebrew-'>/<formula name>`

brew install github/gh/gh is a shortcut for brew tap github/gh && brew install gh

It has worked for several years now, but I'm not sure if it's documented anywhere.

Ah, that makes sense. I've never seen that shortcut before, but the tap & brew pattern is more familiar.

I use a similar tool for GitLab [1], I wonder if this will propel GitLab to maybe put some money and effort into officially supporting it.

[1] https://github.com/zaquestion/lab

Yeah, Hub is such a valuable tool for automating common tasks on GitHub such a releasing. Hopefully GitHub CLI will maintain a feature parity with Hub so that people can transition smoothly if needed.

Try `brew install gh` instead, it's part of homebrew/core.

also wondering what is going to happen to hub...

Reply on news.ycombinator.com