hub + gh = GitHub CLI #475

Closed
mislav opened this Issue Feb 5, 2014 · 26 comments

Comments

Projects
None yet
Member

mislav commented Feb 5, 2014

@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 commented Feb 5, 2014

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!

Member

technoweenie commented Feb 5, 2014

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.

Collaborator

jingweno commented Feb 5, 2014

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

Member

mislav commented Feb 5, 2014

@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

Contributor

calavera commented Feb 5, 2014

@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)).

Member

mislav commented Feb 5, 2014

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

Member

mislav commented Feb 5, 2014

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 commented Feb 5, 2014

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.

Member

mislav commented Feb 5, 2014

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.

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 commented Feb 8, 2014

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

cordoval commented Feb 8, 2014

@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 commented Feb 14, 2014

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.

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]
    😉
Contributor

wilmoore commented Jun 22, 2014

Invoke with git hub [args]

👍

Member

mislav commented Jul 26, 2014

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!

mislav closed this Jul 26, 2014

Collaborator

jingweno commented Jul 26, 2014

@mislav 👍

❤️

gohanlon referenced this issue in thoughtbot/laptop Jul 30, 2014

Closed

gh has superseded hub #266

@croaky croaky added a commit to thoughtbot/laptop that referenced this issue Aug 10, 2014

@croaky croaky Switch from `hub` to `gh`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475
6f392bb

@croaky croaky added a commit to thoughtbot/laptop that referenced this issue Sep 1, 2014

@croaky croaky Switch from `hub` to `gh`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475
7bb5e33

@croaky croaky added a commit to thoughtbot/laptop that referenced this issue Sep 23, 2014

@croaky @pbrisbin croaky + pbrisbin Switch from `hub` to `gh`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475
d9a9dfe

@croaky croaky added a commit to thoughtbot/dotfiles that referenced this issue Sep 30, 2014

@croaky croaky Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
03dc617

@mroth mroth added a commit to mroth/scm_breeze that referenced this issue Oct 2, 2014

@mroth mroth `gh` is the new `hub`
`gh` is the new `hub`, rewritten to be fast and efficient.
http://owenou.com/gh/

If has been adopted by GitHub themselves and will replace `hub`
entirely, see:
github/hub#475

This patch simply checks for `gh` as a possible `_git_cmd` in addition
to hub, restoring scm_breeze functionality for people who have switched
to gh.
1e9d60a

mroth referenced this issue in scmbreeze/scm_breeze Oct 2, 2014

Merged

`gh` is the new `hub` #150

@horacio horacio pushed a commit to horacio/dotfiles that referenced this issue Oct 10, 2014

@croaky croaky + Horacio Bertorello Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
91db0b3

@danielnolan danielnolan added a commit to unitio-org/dotfiles that referenced this issue Oct 15, 2014

@croaky @danielnolan croaky + danielnolan Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
8294e22

my 2 cents right after the battle took place: gh new name can be used for go hub which is exactly what it is :-)

muescha commented Oct 27, 2014

My 2 cents:

Let rejected feature request added as plugins commands / options

Collaborator

jingweno commented Oct 28, 2014

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

@jacobsimeon jacobsimeon pushed a commit to jacobsimeon/dotfiles that referenced this issue Oct 30, 2014

@croaky croaky + Jacob Morris Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
d5af71e

@parkr parkr added a commit to parkr/dotfiles that referenced this issue Nov 9, 2014

@parkr parkr gh is now hub is now gh. c987367

@cblunt cblunt added a commit to plymouthsoftware/dotfiles that referenced this issue Nov 20, 2014

@croaky @cblunt croaky + cblunt Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
fd6f535

@bmorrall bmorrall added a commit to bmorrall/laptop that referenced this issue Dec 23, 2014

@croaky @bmorrall croaky + bmorrall Switch from `hub` to `gh`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475
564495a

@bmorrall bmorrall pushed a commit to bmorrall/dotfiles that referenced this issue Jan 30, 2015

@croaky croaky + Ben Morrall Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
140036f

jingweno referenced this issue in octokit/go-octokit Feb 14, 2015

Closed

Can't Merge a Pull Request #81

@chrishaum chrishaum added a commit to chrishaum/dotfiles that referenced this issue Apr 3, 2015

@croaky @chrishaum croaky + chrishaum Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
b41aeb0

@g5pw g5pw added a commit to g5pw/scm_breeze that referenced this issue May 4, 2015

@mroth @g5pw mroth + g5pw `gh` is the new `hub`
`gh` is the new `hub`, rewritten to be fast and efficient.
http://owenou.com/gh/

If has been adopted by GitHub themselves and will replace `hub`
entirely, see:
github/hub#475

This patch simply checks for `gh` as a possible `_git_cmd` in addition
to hub, restoring scm_breeze functionality for people who have switched
to gh.
01ef23d

@manicmaniac manicmaniac pushed a commit to manicmaniac/dotfiles that referenced this issue May 28, 2015

@croaky croaky Use `gh`, not `hub`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475

Matches thoughtbot/laptop:

thoughtbot/laptop@d9a9dfe
4a61f28

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 commented Jun 11, 2015

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.

Member

mislav commented Jun 11, 2015

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

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

Collaborator

jingweno commented Jun 15, 2015

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

@g5pw g5pw added a commit to g5pw/scm_breeze that referenced this issue Mar 16, 2016

@mroth @g5pw mroth + g5pw `gh` is the new `hub`
`gh` is the new `hub`, rewritten to be fast and efficient.
http://owenou.com/gh/

If has been adopted by GitHub themselves and will replace `hub`
entirely, see:
github/hub#475

This patch simply checks for `gh` as a possible `_git_cmd` in addition
to hub, restoring scm_breeze functionality for people who have switched
to gh.
44981aa

@masonlouchart masonlouchart pushed a commit to masonlouchart/scm_breeze that referenced this issue Aug 15, 2016

Test User Swapping the commands check
This commit swaps the two exports of the commands "hub" and "gh" in the
aliases. The fact is the export of "gh" overwrites the previous one, and
the official GitHub client is using "hub" as command.

See github/hub#475.
Closes #209
d4952b5

masonlouchart referenced this issue in scmbreeze/scm_breeze Aug 15, 2016

Closed

Swapping the commands check #210

@jt14den jt14den pushed a commit to ucsdlib/laptop that referenced this issue Nov 3, 2016

@croaky @pbrisbin croaky + pbrisbin Switch from `hub` to `gh`
[gh] is a [hub] reimplementation that's much faster and is now the official
Github CLI. It appears that "hub" is [deprecated].

[gh]: https://github.com/jingweno/gh
[hub]: https://github.com/github/hub
[deprecated]: github/hub#475
9da37e3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment