Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hub + gh = GitHub CLI #475

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

hub + gh = GitHub CLI #475

mislav opened this issue Feb 5, 2014 · 26 comments

Comments

@mislav
Copy link
Member

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

This comment has been minimized.

Copy link

@hkdobrev 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!

@technoweenie

This comment has been minimized.

Copy link

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

@jingweno

This comment has been minimized.

Copy link
Collaborator

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

@mislav

This comment has been minimized.

Copy link
Member Author

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

@calavera

This comment has been minimized.

Copy link
Contributor

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

@mislav

This comment has been minimized.

Copy link
Member Author

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

@mislav

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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

@mislav

This comment has been minimized.

Copy link
Member Author

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

@nielmclaren

This comment has been minimized.

Copy link

@nielmclaren nielmclaren commented Feb 5, 2014

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

This comment has been minimized.

Copy link

@Ocramius Ocramius commented Feb 8, 2014

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

@cordoval

This comment has been minimized.

Copy link

@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

This comment has been minimized.

Copy link

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

@geoff-nixon

This comment has been minimized.

Copy link

@geoff-nixon geoff-nixon commented Mar 3, 2014

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

This comment has been minimized.

Copy link
Contributor

@wilmoore wilmoore commented Jun 22, 2014

Invoke with git hub [args]

👍

@mislav

This comment has been minimized.

Copy link
Member Author

@mislav 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 mislav closed this Jul 26, 2014
@jingweno

This comment has been minimized.

Copy link
Collaborator

@jingweno jingweno commented Jul 26, 2014

@mislav 👍

@pengwynn

This comment has been minimized.

Copy link

@pengwynn pengwynn commented Jul 29, 2014

❤️

croaky added a commit to thoughtbot/laptop that referenced this issue Aug 10, 2014
[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
@jingweno jingweno mentioned this issue Dec 19, 2014
0 of 2 tasks complete
bmorrall added a commit to bmorrall/laptop that referenced this issue Dec 23, 2014
[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
bmorrall pushed a commit to bmorrall/dotfiles that referenced this issue Jan 30, 2015
[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
christopher-haueter added a commit to christopher-haueter/dotfiles that referenced this issue Apr 3, 2015
[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
g5pw added a commit to g5pw/scm_breeze that referenced this issue May 4, 2015
`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.
manicmaniac pushed a commit to manicmaniac/dotfiles that referenced this issue May 28, 2015
[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
@ferenczy

This comment has been minimized.

Copy link

@ferenczy ferenczy commented Jun 11, 2015

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

This comment has been minimized.

Copy link

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

@mislav

This comment has been minimized.

Copy link
Member Author

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

@ferenczy

This comment has been minimized.

Copy link

@ferenczy ferenczy commented Jun 15, 2015

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

@jingweno

This comment has been minimized.

Copy link
Collaborator

@jingweno 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 added a commit to g5pw/scm_breeze that referenced this issue Mar 16, 2016
`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.
masonlouchart pushed a commit to masonlouchart/scm_breeze that referenced this issue Aug 15, 2016
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 scmbreeze#209
jt14den pushed a commit to ucsdlib/laptop that referenced this issue Nov 3, 2016
[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
@ilovezfs ilovezfs mentioned this issue Aug 17, 2017
2 of 4 tasks complete
veySky pushed a commit to veySky/dotfiles that referenced this issue Feb 18, 2019
[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
anhvy pushed a commit to Thinkei/eh-starter-kit that referenced this issue Jul 1, 2019
[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
anhvy pushed a commit to Thinkei/eh-starter-kit that referenced this issue Jul 1, 2019
[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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.