Imagine working for GitHub and writing a command-line interface for the platform, then GitHub makes an 'official' one
- Reference: 1600694409
- News link: https://www.theregister.co.uk/2020/09/21/github_commandline_interface_v1/
- Source link:
The hosted repository is based on git, which is itself a command-line tool. There is also another project, called [1]hub , which provides a CLI for GitHub. Confusing?
Git alone is not enough for the full GitHub experience, since git is just the repository. Using GitHub Issues, for example, is not a feature of git. Hub wraps git so it supports all git commands, but extends these commands and adds new GitHub-specific commands to manage things such as Issues.
If we have hub, why GitHub CLI? An [2]official document explained: "We wrestled with the decision of whether to continue building onto hub and adopt it as an official GitHub project. In weighing different possibilities, we decided to start fresh without the constraints of 10 years of design decisions that hub has baked in and without the assumption that hub can be safely aliased to git.
"We also wanted to be more opinionated and focused on GitHub workflows, and doing this with hub had the risk of alienating many hub users who love the existing tool and expected it to work in the way they were used to."
GitHub CLI is official, we are told, whereas hub is "a project whose maintainer happens to be a GitHub employee". The new tool is not an exact replacement so hub will continue.
[3]
Using GitHub CLI to list project issues
GitHub CLI has expanded since the beta in February. One big change is that it now supports GitHub Enterprise Server, the self-hosted version of GitHub. There are also new features, such as the ability to clone, create, and fork repositories, use SSH instead of HTTPS, configure a default editor, and fully manage issues and pull requests, complete with reviewing differences and performing merges. You can also set aliases to make shortcuts for one or more commands.
We installed GitHub CLI on Windows using a downloaded installer – which, as noted in [4]one of the issues , incorrectly installs to Program Files (x86) even though it is a 64-bit application. It is available for macOS, Linux, and Windows. macOS users are directed to Homebrew and MacPorts, Linux users have to add a repository and use apt, while for Windows the official documentation directs developers to the scoop or Chocolatey package managers. Curiously, the docs do not currently suggest Microsoft's official [5]Windows Package Manager (Winget) even though GitHub CLI 1.0 is already available there. This might be because Winget is still in preview, or evidence that GitHub still runs with a degree of independence from Microsoft, its owners.
The tool itself worked nicely for us, despite a fair number of [6]reported bugs . The advantage for developers is not only the ability to write scripts using GitHub, but also reducing the need to visit the GitHub website – avoiding, for example, [7]unwelcome design decisions . ®
Bootnote
We have no actual insight into how hub's dev or devs actually feel about this...
Get our [8]Tech Resources
[1] https://github.com/github/hub
[2] https://github.com/cli/cli/blob/trunk/docs/gh-vs-hub.md
[3] https://regmedia.co.uk/2020/09/21/issue-list.png
[4] https://github.com/cli/cli/issues/1841
[5] https://github.com/microsoft/winget-cli
[6] https://github.com/cli/cli/issues?q=is%3Aissue+is%3Aopen+label%3Abug
[7] https://www.theregister.com/2020/06/25/github_redesign_wins_mixed_reception
[8] https://whitepapers.theregister.com/
Re: Microsoft GitHub
It's so nice of Microsoft to embrace the thriving Git ecosystem, and extend a core interface with specific functionality for their own platform.
...by not going with the tool that can be aliased to git (and therefore 'extended' with breaking features) but instead one that specifically ensures you know you're working with GithHub?
They really are losing their touch.
Re: Microsoft GitHub
They're going to make it eXcellent, right? That's the next step?
Re: Microsoft GitHub
"I can only imagine what might come next!"
It doesn't look like a "next" is needed, as once you start replacing cli tools with proprietary ones, the trap is sprung. In fact, maybe the non-official tool was the beginning... not sure as I don't use github.
What is kind of the odd is that you need none of this. SSH works just fine with Git and just because GitHub has or hasn't allowed certain options doesn't mean you need a proprietary cli tool... just fix the back end and be done.
Oddly, the article makes it sound like GitHub is a nightmare to use...
"The advantage for developers is not only the ability to write scripts using GitHub, but also reducing the need to visit the GitHub website"
So, before you couldn't write scripts in ANYTHING and you NEEDED to use the HTML interface... sounds horrible. Ironically(?), it sounds a lot like Powershell (non-portable scripts written for 1 interface).
Same dev?
"We have no actual insight into how hub's dev or devs actually feel about this..."
A cursory look at the contributors to hub and the new CLI shows the same guy behind most of the hub commits is heavily involved with the new CLI. I'm guessing he feels fine about it all?
Re: Same dev?
"feelings" are SO overrated. Although, you don't want _anger_ from customers/users...
And yet I'm still in "wait and see" mode. Last thing I'm going to want to deal with is a closed-source application that must be installed on non-windows (including FreeBSD) development systems, that have cryptic commands similar to Power[s[Hell, requires ".Not" or Mono to run, etc. etc. etc..
Did the article say whether this GitHub "hub" tool is actually OPEN SOURCE? I suppose I could go look at the site... ok - [1]Build from Source instructions are at THAT link! So far so good, except you have to install 'go' 1.13 or later. and here I was thinking that REAL cli application developers use C and C++ ...
(but at least it's Open Source so kudos to the dev for doing that much and making it buildable on non-windows platforms)
Yeah no doubt it'll show up in FreeBSD's ports system soon, if it's not there already.
[1] https://github.com/cli/cli/blob/trunk/docs/source.md
Re: Same dev?
> So far so good, except you have to install 'go' 1.13 or later. and here
> I was thinking that REAL cli >application developers use C and C++ ...
They do. GitHub guys and many of their developers are web developers where they use almost any language that gives them the opportunity to drag in as many dependencies as possible. I wouldn't be surprised if this cli program *also* requires Python 2, Python 3 and Perl ;)
I notice the same unfortunately with Emscripten. It is a little bit webby where 99% of it is C++ from Clang/llvm but for that tiny remaining 1% it drags in Node, Java, Python and a shed load of NPM dependencies. It is a great tool but I really wish it was developed by an actual C or C++ developer.
"start fresh without the constraints of 10 years of design decisions"
Great idea. Now you can make all the same mistakes than before, along with some brand new ones, but in an entirely new way.
Microsoft GitHub
It's so nice of Microsoft to embrace the thriving Git ecosystem, and extend a core interface with specific functionality for their own platform. I can only imagine what might come next!