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

[cordoval]

@Ocramius well we have for instance a versioneye command to update dependencies, but that goes a bit geared toward package maintainers and contributors flow (hence the name Gush), and even we have started a gushbot.io open source REST as an aggregator of service statuses to better power FOSS development. I think you guys idea of moving this to Go is interesting. Good idea! I will be following closely your efforts.

[deiga]

I'm all for keeping it as hub as you're not really doing a new thing, and it neatly points to being a GitHub tool, without ned for acronyms. Shortness really doesn't matter, since the preferable usage is to alias it.

[geoff-nixon]

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.

@mislav Recall that the old github-gem (which is still what's installed with gem install github) already installs a gh, and a github, and as I imagine the go implementation will not be distributed as a gem, on any system where the current hub, or the old github was installed via gem, if $GEM_PATH/bin comes before wherever the new hub or gh is installed, it won't get invoked until this is corrected. So...

how do we call the executable?

Maybe... like any other git subcommand?

• Install it as git-hub anywhere in the path.
• Invoke with git hub [args]
  😉

[wilmoore]

Invoke with git hub [args]

👍

[mislav]

I've just met with @jingweno here in Vancouver and we hacked on the Go version of hub. To answer my initial questions:

1. I think we will name the executable gh eventually, but symlink it as hub as well for backwards compatibility.
2. We'll keep complete backwards compatibility, sans features that were deprecated in hub v1.x.
3. The next release will be v2.2.0, since jingweno/gh is already on v2.1.0 and I think it would be a good idea to continue from there.

I don't think we'll make a big deal out of v2.2 release or label it as "official GitHub CLI" just yet. We want existing users of hub or gh to upgrade and tell us their thoughts and report bugs first, which will certainly be plentiful since it's a complete rewrite. The next version after that (v2.3) will be a bigger deal.

Gonna close this now as we've gathered enough feedback for now. The rest of the conversation will hapen in individual issues. Thanks, everyone!

[owenthereal]

@mislav 👍

[pengwynn]

❤️

[owenthereal]

@muescha Not sure about the rejecting feature requests part 😺, but we do plan to make hub plugable. Stay tuned for future release.

[ferenczy]

I'm just wondering one thing: why is the hub executable so huge now (9.5 MB both Linux and Windows builds of version 2.2.1)?

Until now, I have been using the previous version written in Ruby (1.x) and for example version 1.12.2 had 84 kB. That's quite corresponding with what it does. But 9.5 MB is extremely huge. Why is that? Does it contain the Go interpreter? But even the whole Go interpreter can't be so huge, I guess.

Thank you :)

[methane]

You're right.
While Go is not an interpreted language, executable contains runtime (GC, scheduler) and large part of standard library.
It makes deploy very easy. One binary contains all.

[mislav]

@methane is correct. We don't believe that people are so low on disk space that a 10MB binary would be a problem.

@ferenczy Ruby implementation was small but it was much slower and required Ruby on the system. The new binaries may be distributed without any extra dependencies to install.

[ferenczy]

Thank you guys. But still it seems way too much to me. It's caused by a library(ies) included most probably. Whole Python interpreter is about 2 MB (3.4), 1.7 MB (2.7), 800 kB (2.2), Lua under 100 kB. According what I have googled, simple "Hello world" binary in Go is also up to 2 MB (depending on a version of a compiler).

[owenthereal]

@ferenczy I wouldn't worry too much about the binary size. With the download speed nowadays, it takes less than 100 ms to download hub. There're benefits to write hub in Go, e.g., lower memory usage, faster speed, easier to install etc.