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

gh vs hub #312

Open
mxplusb opened this issue Feb 5, 2020 · 16 comments
Open

gh vs hub #312

mxplusb opened this issue Feb 5, 2020 · 16 comments
Labels

Comments

@mxplusb
Copy link

@mxplusb mxplusb commented Feb 5, 2020

Describe the feature or problem you’d like to solve

It's unclear what the difference between gh and hub are, and when one would be used over the other.

Proposed solution

Merge or provide a descriptive document on the differences and when one would be used vs the other.

Additional context

None.

@vilmibm

This comment has been minimized.

Copy link
Collaborator

@vilmibm vilmibm commented Feb 5, 2020

I think this kind of doc file would be useful. I'd love @mislav 's input on it, though.

@vilmibm vilmibm added the docs label Feb 5, 2020
@tierninho

This comment has been minimized.

Copy link
Contributor

@tierninho tierninho commented Feb 5, 2020

From the ReadMe:

For many years, hub was the unofficial GitHub CLI tool. gh is a new project for us to explore what an official GitHub CLI tool can look like with a fundamentally different design. While both tools bring GitHub to the terminal, hub behaves as a proxy to git and gh is a standalone tool.

This is @mislav response to a similar question:

Hi, this is a great question, and one that we (the GitHub CLI team) intend to clarify further in the near future as we unroll more documentation for gh.

It's correct that gh and hub solve similar problems; as of now both have features for working with issues and pull requests in the current repo, for example. There will inevitably be some overlap between what these tools do, but gh does not aim to implement everything that hub does. Instead, we are reimagining what a GitHub command-line experience can be like from the ground up.

For now, nothing changes for hub: it will still work and it will receive bug fixes for the foreseeable future.

Thanks for using, and please reach out if you have further questions.

@shihrer

This comment has been minimized.

Copy link

@shihrer shihrer commented Feb 13, 2020

One of the questions I still have is what makes hub "unofficial" compared to gh?

@waldyrious

This comment has been minimized.

Copy link

@waldyrious waldyrious commented Feb 14, 2020

I'm also wondering what exactly "a fundamentally different design" and "we are reimagining what a GitHub command-line experience can be like" mean. Perhaps the design goals are still in flux, but if so it would be nice to make this clearer, as well as indicate what the current thinking is, and particularly how much of a role user input will play in defining/refining the design direction.

That said, I'm just making some doubts explicit, not asking for immediate clarification. I'll assume that

we (the GitHub CLI team) intend to clarify further in the near future as we unroll more documentation for gh

will answer these questions.

@benknoble

This comment has been minimized.

Copy link

@benknoble benknoble commented Feb 14, 2020

This, please. I came to write basically the same issue: what does gh offer that hub doesn't? And now that I've read it, why is hub considered unofficial, when it's a github project?

Plus, the hub features (such as for working with remotes as benknoble/repo) should be considered, even for a "new" experience.

@mxplusb

This comment has been minimized.

Copy link
Author

@mxplusb mxplusb commented Feb 14, 2020

When you alias hub, you get these "native" features:

These GitHub commands are provided by hub:

   api            Low-level GitHub API request interface
   browse         Open a GitHub page in the default browser
   ci-status      Show the status of GitHub checks for a commit
   compare        Open a compare page on GitHub
   create         Create this repository on GitHub and add GitHub as origin
   delete         Delete a repository on GitHub
   fork           Make a fork of a remote repository on GitHub and add as remote
   gist           Make a gist
   issue          List or create GitHub issues
   pr             List or checkout GitHub pull requests
   pull-request   Open a pull request on GitHub
   release        List or create GitHub releases
   sync           Fetch git objects from upstream and update branches

What does gh provide that hub doesn't, and why would the experience not be focused on continuing to work on hub? Now there's 2 tools, clear confusion as to support, but both are being actively developed. I don't see the benefit of gh, to be honest.

@maxandersen

This comment has been minimized.

Copy link

@maxandersen maxandersen commented Feb 15, 2020

I think https://mislav.net/2020/01/github-cli/ explains it quite well.

@mislav

This comment has been minimized.

Copy link
Collaborator

@mislav mislav commented Feb 19, 2020

Off the top of my head, the feature comparison right now would be:

overlap of gh & hub:

  • listing issues and PRs
  • creating issues and PRs
  • opening an issue/PR in a browser
  • checking out PRs by number

gh distinctive features:

  • check out PRs by OWNER:BRANCH syntax
  • issue/pr status commands
  • showing Checks and Reviews status for PRs
  • gh pr create automatically forks the parent repo if needed
  • choose between multiple templates on issue/pr create
  • query information from a different repo via --repo OWNER/REPO

hub distinctive features:

  • supply more fields when creating issues/PRs
  • ci-status - view the status of Checks for a branch or commit
  • manage Releases
  • browse - open the repo web page
  • create, fork, and delete repos
  • create and show Gists
  • sync - fast-forward local branches
  • extend git commands: am, checkout, clone, remote, etc.
  • proxy other commands to git
  • scripting:
    • hub api
    • specify --format string for issues/PRs/releases/ci-status output
  • authenticate via username+password on the command line (this API feature is generally being deprecated at GitHub)
  • support for Personal Access Token
  • GitHub Enterprise support

I'm not sure where it's best for this document to live at, but it's going to have to be updated often as we add new features to GitHub CLI.

@jeffhollan

This comment has been minimized.

Copy link

@jeffhollan jeffhollan commented Feb 20, 2020

@mislav good recap - but does make me wonder why all the gh unique stuff couldn’t be added to hub? IMO it feels it snaps into how envisioned a perfect hub option would do. I personally alias git with hub, and would love to just have “git” be my one tool to all the features listed above.

@mislav

This comment has been minimized.

Copy link
Collaborator

@mislav mislav commented Feb 20, 2020

@jeffhollan Good question. We didn't add it to hub because we decided to design GitHub CLI differently than being a git wrapper, i.e. as its own command. It turns out, maintaining an executable that's a proxy to git is hard to maintain, and also we didn't want to be limited by having to always keep git compatibility. We didn't want to build GitHub CLI on a paradigm that is brittle from the start.

@jeffhollan

This comment has been minimized.

Copy link

@jeffhollan jeffhollan commented Feb 20, 2020

Very cool. Yeah I think that level of transparency and documentation is what I think this issue is about. I think that idea (above) and clarifying and stating that this is "official" while the other one is "unofficial" (and ideally what that means? I suspect it means this one has a team at GitHub responsible for upkeep and development while the other doesn't?) would make it super clear why gh and hub may likely never merge

@benknoble

This comment has been minimized.

Copy link

@benknoble benknoble commented Feb 20, 2020

@mislav just wanted to add that your rationale in the linked post makes sense, but I also see @jeffhollan's point: for many of us, this felt kind of sudden. (See the troubles at StackExchange for why that might leave a bitter taste for some, or at least leave some wondering what's happening.)

@mislav

This comment has been minimized.

Copy link
Collaborator

@mislav mislav commented Feb 21, 2020

just wanted to add that your rationale in the linked post makes sense, but I also see @jeffhollan's point: for many of us, this felt kind of sudden.

Sure, I understand.

See the troubles at StackExchange for why that might leave a bitter taste for some

We'd appreciate links 🙇

@benknoble

This comment has been minimized.

Copy link

@benknoble benknoble commented Feb 21, 2020

links

@mislav it's a complex issue if you're not already aware; the point is that transparency and community feedback is a good thing. Again, having read the article you linked, I feel better about the whole thing.

A starting point: https://meta.stackexchange.com/q/334575/389795

@mislav

This comment has been minimized.

Copy link
Collaborator

@mislav mislav commented Feb 21, 2020

A starting point: https://meta.stackexchange.com/q/334575/389795

Thank you. At first I thought you were referring to some questions filed on StackExchange about GitHub CLI, but now I'm guessing that you merely drew a parallel to how the lack of transparency can make a community feel unheard/disrespected.

Our omission of some kind of comprehensive hub vs. GitHub CLI document at the time of the GitHub CLI announcement was intentional, even though we were aware that this incurs a risk of some confusion:

  • We didn't want to make it sound like GitHub CLI supersedes hub. Even though it might not seem that way to the community, these are separate projects with separate design, maintenance, and release philosophies. They just happen to cover some of the same ground.

  • We didn't want to make it sound like these two tools are intended for the same audiences. We are not trying to win over any hub superfans to use the new tool, since they will inevitably be disappointed about the (current) lack of features.

  • We couldn't be fully transparent about our grand vision for GitHub CLI because our vision isn't fully formed yet. Our intention was to release early, release often, iterate based on community feedback, and avoid repeating the same design mistakes that I've made with hub.


People have been asking me: what makes this tool “official”, and how come hub is not that? The answer was always clear in my head, but it took me some time to articulate it. I think I can say right now that the distinction is in responsibility:

  • If hub is broken, or doesn't get a release for too long, or generally results in a poor experience when using it, then some guy called Mislav is responsible. 💁‍♂ You are mostly dependent on his goodwill and the amount of time he has in the evenings and weekends.

    (This is not to say that I'm gatekeeping hub in any way; it just so happened that, historically, I was the only person who stepped up for long-term maintenance of the project.)

  • If GitHub CLI is broken, or results in a poor experience, then GitHub (the organization) is responsible. There is a whole team that will read every issue and PR that comes in, plus you can tweet to us, write to support@github.com about your experience, etc.

Personally, the way I choose to use a certain tool or library over the long term is that I choose how to allocate my trust. I hope that an organization officially backing a project will result in people finding it easier to trust and having a better experience with it in the long term.

@benknoble

This comment has been minimized.

Copy link

@benknoble benknoble commented Feb 21, 2020

@mislav Thank you for understanding and articulating that so well. (And apologies for not being clearer with the connections I was drawing.)

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
9 participants
You can’t perform that action at this time.