hub + gh = GitHub CLI

[mislav]

@technoweenie had this idea (backed by @calavera) that we adopt the awesome work on the Go port of hub (by @jingweno) as the official GitHub thing and call it “GitHub CLI”.

I 👍 this. My Ruby implementation of context.rb is getting unwieldy and in hub v1.11 I feel I've reached the limit of how much I can speed up hub exection. I can't make it much faster than 50 ms due to Ruby interpreter slowness. Go port can execute in under 10 ms, and it's not even specially optimized yet. Go port can also be distributed as a pre-compiled binary, skipping the need to install Ruby, which can be especially tricky and error-prone for Windows users.

I've merged jingweno/gh with hub and pushed that to the "gh" branch here. It's all still rough, but it's a good start. More than half of the Cucumber suite in features/ already passes. The plan is that the next major release of hub will be Go-powered and our Ruby implementation gone by that point.

Some open questions:

1. The project is publically going to be called “GitHub CLI”, but how do we call the executable? Ideally users would alias it as git, so it doesn't matter. We can keep it as hub for compatibility, or we could name it gh for shortness.
2. The next release will be a major release, so we can afford breaking API changes, but how much backwards compatibility do we want to keep? I say as much as possible, sans stuff that is currently deprecated and which we'll drop. That means we should support:
   • Existing commands. I'm open to breaking & improving hub browse, though.
   • YAML configuration in ~/.config/hub, although we should save the OAuth token elsewhere.
   • hub.protocol & hub.host git config options. But we could move the values to YAML config.
3. Version number of the next release? I suggest the obvious v2.0.0.

/cc @defunkt since hub was originally his baby

[hkdobrev]

The project is publically going to be called “GitHub CLI”, but how do we call the executable?

I suggest you keep the old Ruby implementation as hub for maximum backwards compatibility and come up with a new name like gh for the Go implementation. This way you could have most commands backwards compatible in the next version, but you would not have to think about every detail. Everyone would have to install the new executable not via RubyGems anyway. Just keep the hub gem with or without bug fixes. You don't have to drop it entirely.

YAML configuration in ~/.config/hub, although we could start saving the OAuth token elsewhere

I think JSON is far more popular. YAML is popular only in the Ruby world. The ~/.config/hub could support YAML for BC if you want.

Version number of next release? I suggest the obvious v2.0.0.

Definitely v2.0.0. I'll be especially happy if you drop the obsolete v prefix.

---

Just my two cents. Keep being awesome!

[technoweenie]

I think hub is fine for the executable and the config prefixes/filenames. Trying to migrate various "hub.*" config settings across repositories isn't worth the effort.

[owenthereal]

I'd add that gh is more than just a hub clone. With the merge of two projects, the new hub will additionally have autoupdate, crash report, releases, issues, gists (in progress, may not be in time), and a high level of backward compatibility 😸.

[mislav]

@jingweno Oh, thanks for reminding me about a topic I've forgot to bring up, and that is extra features of gh: namely Releases, Issues, Gists support. Historically I've rejected such feature requests because they're not related to git, and hub was a git wrapper.

Now that the project is becoming “GitHub CLI”, would we be open to make it a more generic GitHub API client, with features not necessarily tied to git? I'm open to that, although I've avoided adding issues support in the past mostly because of the amount of work involved with that, and because better tools already exist such as ghi.

However, initially I would suggest only adding support for creating Releases & Gists, since they're easy (ideally replacing the Ruby-based gist library), and managing Pull Requests, since they're related to git workflow and we already support creating them. I would do managing of Issues last, if ever, since it would be the most complex feature with many moving parts (labels, milestones, assignees, searching, ordering).

/cc @technoweenie @calavera; @pengwynn because octonaut

[calavera]

@mislav, creating and listing issues is already there, as well as creating and listing releases.

On Wednesday, February 5, 2014 at 4:01 AM, Mislav Marohnić wrote:

@jingweno (https://github.com/jingweno) Oh, thanks for reminding me about a topic I've forgot to bring up, and that is extra features of gh: namely Releases, Issues, Gists support. Historically I've rejected such feature requests (https://github.com/github/hub/issues?labels=nope&page=1&state=closed) because they're not related to git, and hub was a git wrapper.
Now that the project is becoming “GitHub CLI”, would we be open to make it a more generic GitHub API client, with features not necessarily tied to git? I'm open to that, although I've avoided adding issues support in the past mostly because of the amount of work involved with that, and because better tools already exist such as ghi (https://github.com/stephencelis/ghi).
However, initially I would suggest only adding support for creating Releases & Gists, since they're easy (ideally replacing the Ruby-based gist library (https://github.com/defunkt/gist)), and managing Pull Requests, since they're related to git workflow and we already support creating them. I would do managing of Issues last, if ever, since it would be the most complex feature with many moving parts (labels, milestones, assignees, searching, ordering).
/cc @technoweenie (https://github.com/technoweenie) @calavera (https://github.com/calavera); @pengwynn (https://github.com/pengwynn) because octonaut (https://github.com/pengwynn/octonaut)

—
Reply to this email directly or view it on GitHub (#475 (comment)).

[mislav]

@calavera I've seen that. I was asking whether we want to ship that with next version of hub, i.e. whether we want to commit to maintaining those features and making them more useful.

Right now listing issues is little useful: it doesn't support pagination, doesn't cache results, you can't filter based on label or assignee (e.g. can't fetch your own issues as a TODO list), it displays URLs in the terminal which is of little use since you can't click on them… See #351 (comment) for my comments on what user experience would I like to have for an issues/PR browser.

[mislav]

As for Releases: I've just tried to use release create to write release notes for tagged version pushed to a repository. I got:

2014/02/05 16:52:20 fatal: The assets directory doesn't exist:
  /Users/mislav/p/ruby-build/releases/v20131028

So I can't even create a release without uploading a binary asset. These features are half-baked. If we commit to shipping this, it means spending some time to make them better.

[pengwynn]

I'm 👍 on ditching octonaut and putting my efforts into the new CLI. Honestly, I don't have a big preference on the executable name because I alias to git anyway.

If we commit to shipping this, it means spending some time to make them better.

Agreed. @mislav is the plan to keep the Cucumber specs? That's a Ruby dependency for development, but I think it's more than worth it.

[mislav]

Yep, keeping all cukes. This is the most reliable way to ensure compatibility with last stable release of hub. Right now a lot of them are failing in the "gh" branch but we're working on it.

[nielmclaren]

Perhaps instead of gh or hub you should give it an obnoxiously long name that will encourage users to alias to git. Like gitaculous or hubbernaut. How many times would you type that out before aliasing it? (-:

[Ocramius]

You may want to check https://github.com/cordoval/gush, which is focused on releases afaik /cc @cordoval