I've been using Hub[1] (though not aliased to `git`) for years now, and it's PR management capabilities have been invaluable working on larger projects. Hopefully GitHub CLI is as stable and reliable!
It looks like the main features I use from Hub are already well-supported in the GitHub CLI, and it looks like whether or not Hub will still be maintained is an open question[2].
Edit: Just noting that `brew install github` doesn't work, it's actually `brew install github/gh/gh` — that's a new format for brew packages I haven't seen before.
One thing I really hope they keep from Hub is the way it creates pull requests, namely by opening $EDITOR and using the first line as the PR title and the rest as description, ie. exactly the same mechansim as git uses for "git commit".
Needing to navigate a menu to set title and description as it seems to show in the screenshots seems like completely unnessecary friction.
> first line as the PR title and the rest as description
> exactly the same mechanism as git uses for "git commit"
That's not how git commit works. git commit opens $EDITOR and makes a list of lines (sans commented-out lines) from that. The first line being a title is only convention, whereas in a github PR it's a formal element of the system.
It's not really just convention. Git commit messages map directly to emails for workflows that don't use web UIs like GitHub, with the first line being the subject and the rest being the email body. That's how you mail a commit to someone else for them to review it or incorporate it into their local repo.
If you don't format your commit messages properly then they'll just be a sloppy mess in any email-based workflow (like what Linux uses).
And the first line is the only line that's displayed in contexts like `git log`, so it truly is the commit summary even if you aren't emailing commits.
For the title, it prompts, then for the description, it lets you either enter an editor of your choice.
The thing I like most about it in a little use today, though, is when it goes to create the PR, it lets you choose to create it directly, or open a 'preview' of the PR in the browser. This is nice for creating Draft PRs which you're still working on and should not yet be merged (since, right now, there's no way to create a PR then put it back into 'Draft' state).
I stopped using hub to create PRs because it wouldn't fill in the issue template. I don't know if that's ever been fixed. Instead I used it to "compare" my changes, which opens the page in the browser with the "create pull request" button available where I go through the in-browser PR flow.
It definitely uses the issue template nowadays, if there is one. If there isn't, and the PR is one commit, it will reuse the commit message. If it's multiple commits, it'll give you a commented out list of every commit message, which I generally then give a title to and munge down into a description.
> Edit: Just noting that `brew install github` doesn't work, it's actually `brew install github/gh/gh` — that's a new format for brew packages I haven't seen before.
It's not new, but what you've perhaps seen is more like `brew install OJFord/formulae/gh` - 'most' (I haven't surveyed, but in my experience) people call the repo `homebrew-formulae`, `homebrew-` gets stripped, leaving:
> `<GH user>/<repo name less 'homebrew-'>/<formula name>`
Hi! I'm on the team building GitHub CLI. We're definitely eager for your feedback on what things feel like they're missing, and especially if something is broken or doesn't feel stable or reliable. Feel free to open an issue if there's anything that stands out.
The different homebrew installation you referred to is because `gh` isn't part of homebrew/core yet as it's very new. So we'll be adding it in the coming months, but for now that's just a way for us to maintain our own tap and still provide an easy install/upgrade path.
Just installed it on fedora using dnf and tried my usual git commands using hub instead. So far so good. I haven't tried any hub specific features yet though.
Thanks! I'm definitely curious what you think when you start venturing into creating and checking out PRs in particular, and how we're managing the `pr status` and `issue status` commands in terms of what's shown vs. what you expect or would like to see to get the most relevant context.
Thanks for the shout! That was a community contribution and I totally missed it! It was an outdated version, but should now be updated to the latest 0.5.4. Really appreciate you sharing this. :)
Huh, I'm confused that this announcement doesn't even mention the existing `hub` tool, which is also in the `github` organization... this is a new rewrite replacement for it?
I agree the main thing I use `hub` for is PR management. Specifically creating PRs.
It had seemed to me that hub was somewhat undermaintained lately, so I guess I'm glad they've released a new tool which appears to maybe cover the same things, which perhaps will be better maintained.... but confused that they are releasing a new tool which does the same thing as an already existing tool also from github...
Hub was created by Chris Wanstrath, one of the original GitHub founders, so it's not surprising there's no reference to it. There's a damnatio memoriae of GitHub's founders and founding story because of certain subcultures that were fostered there by the people they chose to hire.
Circa 2014 there was a big blowup of allegations centering around then-CEO Tom Preston-Werner and his wife (not an employee, but worked at the office). Tom resigned as a result.
I don't know why Wanstrath would be excised from collective history though - he was founding CEO (2008-2012) and stepped in again after Tom (2014-2017). Wikipedia says he's now a technical fellow at MS since the acquisition.
So dumb, these are the people who literally created GitHub, show them the damn respect they deserve. `hub` (a tool I use to this day) is clearly the predecessor to this official CLI.
No disrespect to hub whatsoever, and it helped inspire much of how we've thought about `gh`. We're fans of hub too and just decided to take this in a bit different direction.
Yeah, Hub is such a valuable tool for automating common tasks on GitHub such a releasing. Hopefully GitHub CLI will maintain a feature parity with Hub so that people can transition smoothly if needed.
Though it's kind of annoying when you want to actually modify and iterate on the thing. I prefer interpreted languages when the point of it is to rapidly iterate new features on an API-driven service.
I've been waiting for both a command-line and programmatic way to interface with issues and PRs since forever and had to make do with modifying some ancient Ruby cli (and I don't know Ruby), so at least now they're headed in the right direction. I am fairly certain that Issues-as-Code will transform the way projects are developed & managed so I'm excited to see this get more features.
It was nice that they used Go, although being able to drop a binary is a property of any programming languages with support for AOT compiling into native code.
Before the adoption of shared libraries in mainstream computing during the 80's, it was just how we used to work.
> 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.
But github despises its own 2 founders. As it grew, culture changed and founders became enemies. So it became better to write a new tool rather that cooperating with some people.
Hub has been in development since 2009, for sure the gh team could had cooperated.
That's my point. If a company can release something without being on the hook for it, that's awesome. It encourages them to release half-baked stuff alongside their platinum stuff which is something I desire far more than having them only release stuff that's full-baked.
Simply put, I prioritize more software way more than I prioritize officialness etc.
From my experience, I find that Chocolately has way more packages in their main "bucket" compared to searching for buckets with choco, however, I do like the isolation of installed programs with choco.
Scoop is more opinionated, in that there is a single, canonical version of each app. My experience with chocolately is very different, as there are often multiple different packaged versions of any given app, and you've no idea which is the "best" one.
In general it is much simpler in its design and implementation. Most packages are portable and do not use installers. It doesn't have quite as many packages as chocolatey though.
Switched from chocolatey to scoop a while ago and never looked back. Most package installs don't need admin rights, and for those that do, there's the `sudo` package that it recommends, which is a life saver when working with the terminal on Windows in general.
Were the GitHub devs doing anything before Microsoft bought them? All that comes to mind is Atom. MS seems to have really been a shot in the arm for feature development at GH.
IIRC they were always making some progress but then they raised money + got acquired and I assumed headcount ballooned at that point which allowed them to focus on non-enterprise facing features more.
I've been using hub heavily until last year (haven't used github much since), so I was a bit surprised to see this as news. Seems like it's basically the same thing as Hub with some updates b ut most of the flows (and a bunch more) I see were already available through hub.
There are some really nice features in the PR diff section like line-suggestions. I think that went in before MS but could be wrong. I'm hoping they add multiline suggestions someday.
Also the big one for me is their Desktop Client. It has constantly improved and it makes my life easier. It has only gotten better after MS acquisition. They added rebase and merge support recently. I still do stuff from the command line (interactive rebase the most), but the Desktop Client really improves my workflow.
Hm... Features take some time to get to production. The stuff I use/appreciate most launched either before Microsoft acquired them, or shortly after the deal — so its development predates that.
My understanding from listening to employees on podcasts and such was that GitHub had a lot of technical debt (old Rails versions, hacks on old Rails versions to get features in newer Rails versions, etc) that they were whittling down going into - and shortly after - the MS acquisition.
I was recently looking into CRDTs for text-editing, and was surprised to see that Github devs were working on an experimental text editor (Xray) [1] along with a finer-grained version control system for real-time collaborative editing (Memo) [2]. That project, however, seems to have been lost (and archived) in the Microsoft reshuffling of things.
There are other libraries that I've found and used, Yjs [1] for an example because it supports the text editor (ProseMirror) I'm building upon. However, a good version control system for CRDTs, like git for flat text, does not still exist.
Yeah github seemed to also have some interesting innovations working with in the (programming) language classification domain.
There has been some work done by people from the ML@B over at Berkeley (?) to greatly improve github-linguist, the tool GitHub uses (I think) to identify programming languages in GitHub repositories. The project is named lexicon (used to be hosted at https://lexicon.github.io/ but now it 404s...) and the results seemed very interesting.
Tried pinging github support about open-sourcing this work, but it seems it's not going to happen. I had very friendly and helpful people answering me, and I totally understand not wanting to open-source something. I just feel a bit sad for the lost opportunity.
"Every day, millions of files are uploaded onto Github, a coding repository where users share code and collaborate on projects. But how do you tell what language those files are written in?
Identifying programming languages are surprisingly hard. Symbols used in one language often have different meanings in another. For example, ‘#’ in python indicates a comment, while in C it indicates a preprocessor command. Even worse, code in one language can actually contain code in different languages, such as HTML, which can contain CSS and/or Javascript.
At the moment, Github uses a giant checklist to identify unique quirks in the language. For example, if the code contains “:- module”, then it’s probably"); background-size: 1px 1px; background-position: 0px calc(1em + 1px);"> Mercury. However, most languages simply don’t have enough unique quirks for this method to be accurate enough.
The current solution the Github team at ML@B came up with is to use a machine learning algorithm called a Naïve Bayes Classifier. To optimize the program, they used Github’s checklist as a guideline for choosing the correct language rather than a hard-and-fast rule. Currently, the team is working on scraping Rosetta Code, a large repository of code in hundred of different programming languages, for data that they can use for training the program and testing its accuracy. Eventually, they will want to see if implementing other models, such as neural networks, can improve accuracy."
I'm certain I saw more advanced claims of success on this project and that github knows about it, since last time I asked they were 'still talking about it internally', but every link I had is dead...
Heh, TravisCI got acquired and laid off a bunch of staff but at least externally appear to have increased their velocity.
CircleCI has raised 115M, hire the best people, and are struggling to release a half-baked UI remake that has been in progress for seemingly ever(that is now being forced on everyone this quarter supposedly).
Not sure what the take away is.. Hard to make sense of it externally; interesting things going on under the surface perhaps.
CircleCI's UI is absolutely awful, and the new one isn't much better as it's one of those SPAs that's slow as an old pig and takes ages to load the first time.
There are things I like and dislike about the current UI; most of my dislikes revolving around navigating between workflows and projects(am I on a job? a workflow? how do I get back to this projects workflows?). I think most of their UI issues could have been resolved without a complete re-write. Well, I also dislike they stopped fixing certain bugs in it because they are "totally focused" on the new UI; I have to use it in FireFox now because Chrome hangs.
Given a re-write though, I think the way it's moved forward is a bit of a train wreck:
* It's incomplete information wise.
* They threw the baby out with the bathwater as far as UX. Nice things like when you visit a job with failed tests it high-lights that fact and failures; gone.
* They implemented the new log viewer with a virtual scroller. Browser search can search into it, and it has no integrated search. You can select past the buffer size of course. Zero extra value to the user here.
* It seems like the people working on the project have little product empathy. I would almost think it's been outsourced. When very obvious missing feature or issues(compared to the current UI) are pointed out, we get platitudes like "Thanks for letting us know as we iterate on this. We are all in this together!".
* Supposedly it's now being forced on the user base Q1 2020 in this state.
* As a nit, it's uninspired and ugly as sin IMHO from a design standpoint. It looks like an off-the-shelf Atlassian SPA theme. And janky. Somehow the sidebar got wider AND dropped the test explaining the icons?!
The whole thing seems like a boondoggle of epic proportions. Did I mention they seem to also be simultaneously rolling out GraphQL; because GraphQL?! I'm somewhat surprised and saddened there aren't more people pushing back on it and leaving feedback in their forums. Meanwhile we can't filter entire workflows, and we can't filter for PRs. Sigh.
I do like many aspects of their service, so it's a shame to see something play out like this :/
They may hire the best people. But it matters what they're the best in. You might have the best developers in the world, but that doesn't mean you have any UX/UI designers.
That's how startups work pre-acquisition. Your acquisition price is dependent in part on how "large" the company is, that is, how many employees you have. So the companies start out small, hiring only the folks who know what they're doing, but as time progresses and they start thinking about selling themselves, they hire a bunch of people who have no clue whatsoever, just to pad the numbers. Surely a 500-person company is worth more to the acquirer than a 50 person one, even if those people just slow the core team down to a crawl. Or at least that's the idea. MS itself isn't really a paragon of productivity, so the visible improvement in productivity is quite telling.
People completely ignore/don't notice the incredible polish features Github was releasing all the time. They feel them, but they don't actively notice them.
My 2cents but I have noticed lots of small, minor updates to their front end over the last year. Things like better focus and hover states, branch copying, better mobile layouts, etc. Lots of minor front end polish.
That was an explicit paper cuts project by the GitHub team started prior to the acquisition.
Primary push was the Dear GitHub letter and the isaacs/GitHub repo which documented hundreds of such small issues. Also, the GitHub refined plugin, features of which GitHub keeps reimplementing now.
They were doing 3D object diff tools [0] and the like.
Prior to Microsoft, it seems that the devs had free reign to develop whatever features they wanted, completely undirected by any sense of product management.
We stopped using their enterprise product (which they shipped as an obfuscated ruby blob) because they wouldn't listen to us and help us with the problems we were having.
It's probably also due to the fact that many devs inside Microsoft also use GitHub actively for larger projects.
To me this largely looks like they're actively listening to their own developers, or have a structure in place to allow devs to take the initiative to address the needs they're facing.
But I have zero insight in how MS works internally, so I can only guess :)
Seems to me that Forge already covers all demonstrated features via the GitHub API, so I'm guessing: not at all. Forge is really nice.
(In case 'tarsius is reading this, one thing I would wish for is if Forge could work independent of a git repo. I've seen a pattern in several places now where they run a single project in Gitlab with just the issue tracker, and no associated repository.)
forge and github-review (https://github.com/charignon/github-review) have given me a near-immersion experience for bitesized code reviews in Emacs. They even work together, via github-review-forge-pr-at-point!
The only thing stopping me from using this with larger diffs is the lack of a good way to show more of the surrounding context in github-review. Wonder if there is any interest in making github-review a first-class part of forge.
> Since I personally don’t find it valuable to spend my time maintaining two separate command-line clients for GitHub, I will gradually reduce my involvement with hub to a point where it either goes into complete feature-freeze mode or finds new maintainership.
So it sounds like gh will be the successor to hub.
I switched long back, when I realised that gh was faster, easier to install, and there was no syntax change on the commands.
Edit: I sound very confused in this thread because I still call the old Golang version gh in my scripts. Thought it was the same codebase graduating till I read this.
How does this work with internally hosted github server? When I tried a command on an existing clone folder, it wants to go to github.com to authenticate.
It doesn't - it's just the code on that PR, but you can also use a --preview flag on pr view to get render the body of the PR in your terminal. We may explore something around incorporating comments down the road as well.
Sorry! We're hoping to get to it after gh is out of beta. It's definitely something we're hearing people want, and I'm excited for when we can say it just works. :)
Is there a way to install this without using Homebrew? I know that the author of it works at Github now, but that definitely shouldn't be the only option..
In this case, you can download the prebuilt binaries from the Github repo page itself under the 'Releases' tab. But as with anything in Brew, if you can't find the installable binary or tarball online yourself, you can simply look at the Brew formula to find the URL and download+install it manually.
My cynical side wonders if this is a case of Embrace Extend Extinguish-move developer mindshare off of git (GitHub as commodity git hosting) and into vendor lock-in.
The time to do that was when people asked GitHub to stop providing services to ICE to help run concentration camps for children and their military-industrial complex owners at Microsoft just shrugged and said “whatever”. (It continues to date. Microsoft has always been more than happy to sell software to the violent and authoritarian. The Snowden slides are PowerPoint.)
But yes, time to switch. I highly recommend Gitea + Drone, it’s the setup I use. Gitea thankfully supports U2F (and oauth for logging into Drone) which is awesome, and although they took shit for plainly ripping off GitHub’s UI back when GitHub was beloved, it’s super convenient to have a nearly identical UI to switch to now.
Well that completely passed under the radar. Last year November? Can't remember reading about this ..
Didn't we judge Nokia-Siemens when they did similar, developing DPI infrastructure for Iran and Egypt?
Good on those people resigning over this, that shows some backbone.
> “We do not know the specific projects that the on-premises GitHub Enterprise Server license is being used with, but recognize it could be used in projects that support policies we both agree and disagree with.”
That sounds like when Nokia Siemens Networks provided communications intercept technology with foresight of how the Iranian authorities might use it to violate human rights.
That reasoning does NOT hold, if the "policies we disagree with" part literally equates to children kept in cages.
Then "I'm just making a service, not doing politics" is being wilfully blind.
People resigned over this. That also means, the people who are still there, did not.
It sort of makes sense with MS being the owner. I definitely notice that a lot of the new grads don’t really know about git. They think it’s all Github.
I've had a lot of freelancers lately who when I ask for their ssh public key they send me their GitHub username. Like 10 in a row. Half of them had public keys even.
Yeah, I don't get that. I use my github as a repository of my public keys - At least partially because Ubuntu will now ask for a github username to prefill authorized_keys, but I had a curl script set up before that - But I would not confuse "Here's where there's an updated list of my keys" for "Here's a key"; The response is, at best, `*[]key` rather than `key` (and assuming you know the github.com/$USER.keys syntax, which isn't exactly standard)
For the true pure "EEE" experience. they would need to be pushing us back towards some other MS product.
Embrace git. Extend git. Extinguish git. Everyone is tired of git and just goes to Microsoft VSCode Repos.
With "gh" in theory they could do that: get everyone using a custom tool... and while no one is paying attention, change out the backing infrastructure to use MS Repos Tool. And you wont even notice because gh was built to make the transition seamless. (I doubt this is truly the case because there is a lot of automated tooling that uses git that would break in that case)
And now when you decide you want to pull your code off github to go to gitlab, it becomes too much of a hassle.
I agree. It provides value. If it provides value then why are people against it? Every thread about Microsoft has some knee jerk low effort post about embrace extend extinguish.
This is a CLI for GitHub, not for Git. All the examples are about manipulating issues and pull requests, which are both concepts that do not exist at all in Git. That's the value add of GitHub.
Such posts are not "knee jerk low effort". I had very much the same worries when I read this, and I think those are very legitimate worries, worthy of discussion. It used to be FUD and sometimes knee jerk, until it becomes SOP and "why is anybody surprised by this".
In between those stages there are moments where you can ask "is this where we want to go".
Maybe a better question to ask than "are they doing this for vendor lock-in", is "will this allow them to make a decision to easily increase vendor lock-in" (in which case business forces will make that decision). It doesn't really matter what the motivation is, after all, a corporation doesn't have memory for good intentions.
Frustrating that the CLI is an “open” beta while the iOS and Android clients are not. I’d love to test the iOS beta but I have no idea where I am on the waiting list.
Doesn't it bother anyone that in the first graphic they used typographically correct Unicode quotes, but these quotes won't work in shell? I initially thought that these were screenshots in an actual minimalistic terminal emulator but apparently these are just graphic designs.
This pains me. They saw the "what" but not the "why".
The point of using a command line is not because a VT100 emulator is an ideal way to view data (it's not). It's so we can combine commands, using pipes and redirection. I don't want to learn special new filtering flags. I want to get raw data that I can pipe to grep or cut or any of the other dozens of tools I've been learning and using for the past 25 years.
The point of using a distributed version control system is so I can store it all locally. This new tool defaults to only 30 items, and cannot fetch more than 100. So even if you're willing to put up with the multi-second latency of hitting their servers for every command line operation (it feels like CVS all over again), you still can't say "give me everything and let me grep it". You have no choice but to use the 3 ways they give you to filter (assignee, label, state -- not title, comments, or date).
I've got a 50Mbps network connection, a 500GB SSD, 16GB of memory, and an 8-core CPU, and now instead of putting all that to work running JavaScript to access my bug reports, I'm fetching them as plain text at a maximum of about 5000 bytes at a time. (Net throughput is on par with an Apple II with a 14.4Kbps modem.) Is this an improvement?
I do not understand why GitHub Issues aren't git repos, like most other GitHub collections. Then we wouldn't need a completely new (and slow/complex/limited) tool to read bug reports on the command line. Perlis had this figured out back in 1982: using common tools for disparate data is a killer feature. That's why we're still using the command line in a way that looks nearly identical to how it worked in the 1980's, and a few generations of other interfaces have come and gone since then and failed to displace it.
>I do not understand why GitHub Issues aren't git repos, like most other GitHub collections.
They are probably deliberately avoiding making Github issues available as git repos because they suspect their competitors would copy the format and reduce the effort required to migrate to a different service.
It prints to stdout so you can of course grep your "gh issue list" (or at least the 3 fields that it displays: number, title, labels), but since it silently truncates output to at most 100 records, this doesn't seem terribly useful to me.
It doesn't even print a message or use a nonzero return code to indicate the output is incomplete. What's the point of running "gh issue list | grep foo"? There's no way to distinguish between "there are no 'foo' issues" and "there's 250 'foo' issues (but they happen to not be at the top of the list)".
Code search seems to be out of scope for the CLI. (It arguably doesn't even do issue search -- just basic filtering on a couple predefined fields.) But that's no problem because I've got all my source code on my machine already! I can use grep, git-grep, or any other tool I want (ack/ag/rg are popular).
>I do not understand why GitHub Issues aren't git repos, like most other GitHub collections.
Doing that would make their implementation trickier since they'd have to find a way to make issues play nicely with the git object system which may not be completely trivial. On top of that they have very little incentive to do that because having a custom API and custom tools to access it increases lock-in. If github issues were just git repositories you'd be able to migrate them very easily. I'm sure they very much don't want to decentralize this.
I agree with your general point though, I'm very much a shell power user but I seldom use these tools because they don't seem particularly more efficient than just using the web browser in my experience. As you point out the power of the shell is to combine commands. If I just want shortcuts to list various attributes of the project I can do that with bookmark keywords in firefox for instance.
While the issues aren't a git repo in themselves, their API is actually quite open and usable. I've written a few migration services for a past employer where management insisted on JIRA but developers wanted Github so my service would basically batch migrate changes (issue state, description, comments etc..) from Github to JIRA so management would get the updates while devs used Github solely.
Well, the "why" is certainly "because you use git from the command line; no context switch; CLI is always faster then GUI".
And of course these reasons are poor and hide the fact that with systems like Github (Gitlab and Bitbucket are the same), issue tracking and thelike are locked in. I only know the wiki which can be accessed as git repository (at least in Gitlab and Github). Which other Github "collections" are exposed as git repository?
I'm not convinced that their ad-hoc curse interface is really faster than GUI. First you have commands like "issue view" that... open the browser to display the issue. Then you have commands like "pr create" that seem to ask for tile and then description. What if you want to amend the title while you type the description? Well I guess you can always "preview in browser" when you're done. Might as well just do it from the browser to begin with honestly.
"pr checkout" is the only command that seems truly useful and a time saver to me.
Thanks for the feedback. There's also a --preview flag in the view commands if you want to see the body in your terminal. We're still working on a bunch more functionality, and we intend to add more flags to allow you to customize the things that are most useful to you. But we wanted to get this in people's hands early to get feedback to help inform where we go from here.
The pessimist in me would say that Github doesn't have issues as git repos because it makes migrations off of their platform more difficult. Hence making vendor lock-in stronger.
The optimist would say limiting contributions to issues on web platform made the formatting ( markdown ) consistent. So that linking back to issues and commits was more standard, and therefore made Github Issues a nice tool to use over the competition at the time.
> The point of using a distributed version control system is so I can store it all locally. This new tool defaults to only 30 items, and cannot fetch more than 100. So even if you're willing to put up with the multi-second latency of hitting their servers for every command line operation (it feels like CVS all over again), you still can't say "give me everything and let me grep it". You have no choice but to use the 3 ways they give you to filter (assignee, label, state -- not title, comments, or date).
I love the command line too, and I get what you're saying, but why don't you just use their API?
I don't see why you couldn't just make a repo called <project>-issues and build the workflow into git. Put instructions on how to use inside CONTRIBUTING
198 comments
[ 3.4 ms ] story [ 232 ms ] threadIt looks like the main features I use from Hub are already well-supported in the GitHub CLI, and it looks like whether or not Hub will still be maintained is an open question[2].
Edit: Just noting that `brew install github` doesn't work, it's actually `brew install github/gh/gh` — that's a new format for brew packages I haven't seen before.
[1] https://github.com/github/hub
[2] https://github.com/github/hub/issues/2470
Needing to navigate a menu to set title and description as it seems to show in the screenshots seems like completely unnessecary friction.
> exactly the same mechanism as git uses for "git commit"
That's not how git commit works. git commit opens $EDITOR and makes a list of lines (sans commented-out lines) from that. The first line being a title is only convention, whereas in a github PR it's a formal element of the system.
If you don't format your commit messages properly then they'll just be a sloppy mess in any email-based workflow (like what Linux uses).
And the first line is the only line that's displayed in contexts like `git log`, so it truly is the commit summary even if you aren't emailing commits.
The thing I like most about it in a little use today, though, is when it goes to create the PR, it lets you choose to create it directly, or open a 'preview' of the PR in the browser. This is nice for creating Draft PRs which you're still working on and should not yet be merged (since, right now, there's no way to create a PR then put it back into 'Draft' state).
It has worked for several years now, but I'm not sure if it's documented anywhere.
[0] https://mislav.net/2020/01/github-cli/
[1] https://github.com/zaquestion/lab
It's not new, but what you've perhaps seen is more like `brew install OJFord/formulae/gh` - 'most' (I haven't surveyed, but in my experience) people call the repo `homebrew-formulae`, `homebrew-` gets stripped, leaving:
> `<GH user>/<repo name less 'homebrew-'>/<formula name>`
The different homebrew installation you referred to is because `gh` isn't part of homebrew/core yet as it's very new. So we'll be adding it in the coming months, but for now that's just a way for us to maintain our own tap and still provide an easy install/upgrade path.
Just installed it on fedora using dnf and tried my usual git commands using hub instead. So far so good. I haven't tried any hub specific features yet though.
It is nice that I can just dnf install hub
Unfortunately, it's quite limited. No way to open a specific file, for example, or jump to a specific branch other than the current one.
I'd love to have something like "gh open".
Uploading releases please!
It's been part of homebrew/core for something like two weeks: https://github.com/Homebrew/homebrew-core/blob/master/Formul...
I agree the main thing I use `hub` for is PR management. Specifically creating PRs.
It had seemed to me that hub was somewhat undermaintained lately, so I guess I'm glad they've released a new tool which appears to maybe cover the same things, which perhaps will be better maintained.... but confused that they are releasing a new tool which does the same thing as an already existing tool also from github...
I don't know why Wanstrath would be excised from collective history though - he was founding CEO (2008-2012) and stepped in again after Tom (2014-2017). Wikipedia says he's now a technical fellow at MS since the acquisition.
Knowing how big GitHub is on Ruby and Node.js I was afraid they had used one of these two languages to bootstrap the program.
Being able to drop the binary in any computer and have it work without hundreds of files as dependencies is a bless when you write programs in Go.
[1]: https://github.com/github/hub
Hub was originally a collection of Ruby scripts for ±3 years [1]. They later refactored the code to use Go:
• Initial commit on Dec 5, 2009 was 100% Ruby code [2]
• @jingweno started a refactoring using Go on Apr 8, 2013 [3][4]
• The Go rewrite was merged to master on May 23, 2013 [5]
[1] https://mislav.net/2020/01/github-cli/
[2] https://github.com/github/hub/tree/de9bfa2103ee81a547d4fc598...
[3] https://github.com/github/hub/commit/d5615fcb6f9c983fbf5d129...
[4] https://owenou.com/fast-github-command-line-client-written-i...
[5] https://github.com/github/hub/tree/0df403f14805d4962ee3adb22...
They use Node.js?
lots of languages have that lol
It's what your parent likes about Go. Inventing a claim of uniqueness and then condescendingly dismissing it isn't a good look.
GHC has first-class support for laziness. Rust has affine types.
I've been waiting for both a command-line and programmatic way to interface with issues and PRs since forever and had to make do with modifying some ancient Ruby cli (and I don't know Ruby), so at least now they're headed in the right direction. I am fairly certain that Issues-as-Code will transform the way projects are developed & managed so I'm excited to see this get more features.
Before the adoption of shared libraries in mainstream computing during the 80's, it was just how we used to work.
Edit: found a note in their readme on github: https://github.com/cli/cli#comparison-with-hub
> 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.
'unofficial'... https://hub.github.com/
I officially despise how meaningless '[un]official' has become.
And in the end, since it's open source, it's up to me whether I derive value from it.
OSS is great, I agree, my issue is just with the weird description of GitHub's older similar tool.
But github despises its own 2 founders. As it grew, culture changed and founders became enemies. So it became better to write a new tool rather that cooperating with some people.
Hub has been in development since 2009, for sure the gh team could had cooperated.
Simply put, I prioritize more software way more than I prioritize officialness etc.
Has some good incite in the history of hub, and why they chose to move this direction.
> gh is available via scoop
And I've been using chocolatey the whole time :facepalm.
How does scoop compare to choco? (Except for the obvious "no admin permissions needed")
In general it is much simpler in its design and implementation. Most packages are portable and do not use installers. It doesn't have quite as many packages as chocolatey though.
[1] https://github.com/github/hub/issues/2192
And, not only adding features is doing something; improving reliability or just maintaining the site, monitoring is also work...
So dismissing pre-MS GitHub might not be really appropriate.
[0] https://hub.github.com/
Also the big one for me is their Desktop Client. It has constantly improved and it makes my life easier. It has only gotten better after MS acquisition. They added rebase and merge support recently. I still do stuff from the command line (interactive rebase the most), but the Desktop Client really improves my workflow.
Source: MS employee now works at GitHub
[1] https://news.ycombinator.com/item?id=16525735
[2] https://github.com/atom-archive/xray/tree/master/memo_core
[1] http://yjs.dev/
There has been some work done by people from the ML@B over at Berkeley (?) to greatly improve github-linguist, the tool GitHub uses (I think) to identify programming languages in GitHub repositories. The project is named lexicon (used to be hosted at https://lexicon.github.io/ but now it 404s...) and the results seemed very interesting.
Tried pinging github support about open-sourcing this work, but it seems it's not going to happen. I had very friendly and helpful people answering me, and I totally understand not wanting to open-source something. I just feel a bit sad for the lost opportunity.
[1] https://github.com/github/linguist
"Every day, millions of files are uploaded onto Github, a coding repository where users share code and collaborate on projects. But how do you tell what language those files are written in?
Identifying programming languages are surprisingly hard. Symbols used in one language often have different meanings in another. For example, ‘#’ in python indicates a comment, while in C it indicates a preprocessor command. Even worse, code in one language can actually contain code in different languages, such as HTML, which can contain CSS and/or Javascript.
At the moment, Github uses a giant checklist to identify unique quirks in the language. For example, if the code contains “:- module”, then it’s probably"); background-size: 1px 1px; background-position: 0px calc(1em + 1px);"> Mercury. However, most languages simply don’t have enough unique quirks for this method to be accurate enough.
The current solution the Github team at ML@B came up with is to use a machine learning algorithm called a Naïve Bayes Classifier. To optimize the program, they used Github’s checklist as a guideline for choosing the correct language rather than a hard-and-fast rule. Currently, the team is working on scraping Rosetta Code, a large repository of code in hundred of different programming languages, for data that they can use for training the program and testing its accuracy. Eventually, they will want to see if implementing other models, such as neural networks, can improve accuracy."
I'm certain I saw more advanced claims of success on this project and that github knows about it, since last time I asked they were 'still talking about it internally', but every link I had is dead...
WELL now that I googled seriously, I think I was too pessimistic, there seems to be some movement on this front at github : https://github.blog/2019-07-02-c-or-java-typescript-or-javas...
Excited to see what's coming out of this new endeavour... Just sent an email to github support, fingers crossed.
CircleCI has raised 115M, hire the best people, and are struggling to release a half-baked UI remake that has been in progress for seemingly ever(that is now being forced on everyone this quarter supposedly).
Not sure what the take away is.. Hard to make sense of it externally; interesting things going on under the surface perhaps.
We made the switch, but quickly looked at other options. I can't have a vendor willingly introduce major, breaking changes.
Given a re-write though, I think the way it's moved forward is a bit of a train wreck:
* It's incomplete information wise.
* They threw the baby out with the bathwater as far as UX. Nice things like when you visit a job with failed tests it high-lights that fact and failures; gone.
* They implemented the new log viewer with a virtual scroller. Browser search can search into it, and it has no integrated search. You can select past the buffer size of course. Zero extra value to the user here.
* It seems like the people working on the project have little product empathy. I would almost think it's been outsourced. When very obvious missing feature or issues(compared to the current UI) are pointed out, we get platitudes like "Thanks for letting us know as we iterate on this. We are all in this together!".
* Supposedly it's now being forced on the user base Q1 2020 in this state.
* As a nit, it's uninspired and ugly as sin IMHO from a design standpoint. It looks like an off-the-shelf Atlassian SPA theme. And janky. Somehow the sidebar got wider AND dropped the test explaining the icons?!
The whole thing seems like a boondoggle of epic proportions. Did I mention they seem to also be simultaneously rolling out GraphQL; because GraphQL?! I'm somewhat surprised and saddened there aren't more people pushing back on it and leaving feedback in their forums. Meanwhile we can't filter entire workflows, and we can't filter for PRs. Sigh.
I do like many aspects of their service, so it's a shame to see something play out like this :/
Primary push was the Dear GitHub letter and the isaacs/GitHub repo which documented hundreds of such small issues. Also, the GitHub refined plugin, features of which GitHub keeps reimplementing now.
Prior to Microsoft, it seems that the devs had free reign to develop whatever features they wanted, completely undirected by any sense of product management.
We stopped using their enterprise product (which they shipped as an obfuscated ruby blob) because they wouldn't listen to us and help us with the problems we were having.
[0] https://github.blog/2013-09-17-3d-file-diffs/
To me this largely looks like they're actively listening to their own developers, or have a structure in place to allow devs to take the initiative to address the needs they're facing.
But I have zero insight in how MS works internally, so I can only guess :)
(In case 'tarsius is reading this, one thing I would wish for is if Forge could work independent of a git repo. I've seen a pattern in several places now where they run a single project in Gitlab with just the issue tracker, and no associated repository.)
The only thing stopping me from using this with larger diffs is the lack of a good way to show more of the surrounding context in github-review. Wonder if there is any interest in making github-review a first-class part of forge.
https://www.facebook.com/TribalClashAustralia/
https://www.facebook.com/Rally-Sweden-2020-Live-Online-10714... https://www.facebook.com/Rally-Sweden-2020-Live-110507593858... https://www.facebook.com/Rally-Sweden-2020-102007734721523/ https://www.facebook.com/WRC-Rally-Sweden-2020-Live-Online-1... https://www.facebook.com/WRC-Rally-Sweden-2020-Live-10624078... https://www.facebook.com/WRC-Rally-Sweden-2020-1066217809192...
https://www.facebook.com/World-Champ...
This is the new CLI i want most
I would assume the parent poster wants something richer than a single substitution though?
> Since I personally don’t find it valuable to spend my time maintaining two separate command-line clients for GitHub, I will gradually reduce my involvement with hub to a point where it either goes into complete feature-freeze mode or finds new maintainership.
So it sounds like gh will be the successor to hub.
[0] https://mislav.net/2020/01/github-cli/
Edit: I sound very confused in this thread because I still call the old Golang version gh in my scripts. Thought it was the same codebase graduating till I read this.
https://github.com/github/homebrew-gh/blob/19a5398d3c022e80f...
https://techcrunch.com/2019/11/13/github-faces-more-resignat...
But yes, time to switch. I highly recommend Gitea + Drone, it’s the setup I use. Gitea thankfully supports U2F (and oauth for logging into Drone) which is awesome, and although they took shit for plainly ripping off GitHub’s UI back when GitHub was beloved, it’s super convenient to have a nearly identical UI to switch to now.
Didn't we judge Nokia-Siemens when they did similar, developing DPI infrastructure for Iran and Egypt?
Good on those people resigning over this, that shows some backbone.
> “We do not know the specific projects that the on-premises GitHub Enterprise Server license is being used with, but recognize it could be used in projects that support policies we both agree and disagree with.”
That sounds like when Nokia Siemens Networks provided communications intercept technology with foresight of how the Iranian authorities might use it to violate human rights.
That reasoning does NOT hold, if the "policies we disagree with" part literally equates to children kept in cages.
Then "I'm just making a service, not doing politics" is being wilfully blind.
People resigned over this. That also means, the people who are still there, did not.
Yet at work no one has this issue with our ghe
Embrace git. Extend git. Extinguish git. Everyone is tired of git and just goes to Microsoft VSCode Repos.
With "gh" in theory they could do that: get everyone using a custom tool... and while no one is paying attention, change out the backing infrastructure to use MS Repos Tool. And you wont even notice because gh was built to make the transition seamless. (I doubt this is truly the case because there is a lot of automated tooling that uses git that would break in that case)
And now when you decide you want to pull your code off github to go to gitlab, it becomes too much of a hassle.
Additionally, I think that Git's CLI is fine and there's no reason to put training wheels on it.
In between those stages there are moments where you can ask "is this where we want to go".
Maybe a better question to ask than "are they doing this for vendor lock-in", is "will this allow them to make a decision to easily increase vendor lock-in" (in which case business forces will make that decision). It doesn't really matter what the motivation is, after all, a corporation doesn't have memory for good intentions.
Any reason I'd bother to switch to this?
Basically, it's for the terminal geeks that don't want to bother with using the web interface of GH for daily tasks.
The point of using a command line is not because a VT100 emulator is an ideal way to view data (it's not). It's so we can combine commands, using pipes and redirection. I don't want to learn special new filtering flags. I want to get raw data that I can pipe to grep or cut or any of the other dozens of tools I've been learning and using for the past 25 years.
The point of using a distributed version control system is so I can store it all locally. This new tool defaults to only 30 items, and cannot fetch more than 100. So even if you're willing to put up with the multi-second latency of hitting their servers for every command line operation (it feels like CVS all over again), you still can't say "give me everything and let me grep it". You have no choice but to use the 3 ways they give you to filter (assignee, label, state -- not title, comments, or date).
I've got a 50Mbps network connection, a 500GB SSD, 16GB of memory, and an 8-core CPU, and now instead of putting all that to work running JavaScript to access my bug reports, I'm fetching them as plain text at a maximum of about 5000 bytes at a time. (Net throughput is on par with an Apple II with a 14.4Kbps modem.) Is this an improvement?
I do not understand why GitHub Issues aren't git repos, like most other GitHub collections. Then we wouldn't need a completely new (and slow/complex/limited) tool to read bug reports on the command line. Perlis had this figured out back in 1982: using common tools for disparate data is a killer feature. That's why we're still using the command line in a way that looks nearly identical to how it worked in the 1980's, and a few generations of other interfaces have come and gone since then and failed to displace it.
Wait you can't grep over your case base if you use this tool?
Have they at least improved their code search? Last few times I used it it was very limited.
It doesn't even print a message or use a nonzero return code to indicate the output is incomplete. What's the point of running "gh issue list | grep foo"? There's no way to distinguish between "there are no 'foo' issues" and "there's 250 'foo' issues (but they happen to not be at the top of the list)".
Code search seems to be out of scope for the CLI. (It arguably doesn't even do issue search -- just basic filtering on a couple predefined fields.) But that's no problem because I've got all my source code on my machine already! I can use grep, git-grep, or any other tool I want (ack/ag/rg are popular).
Doing that would make their implementation trickier since they'd have to find a way to make issues play nicely with the git object system which may not be completely trivial. On top of that they have very little incentive to do that because having a custom API and custom tools to access it increases lock-in. If github issues were just git repositories you'd be able to migrate them very easily. I'm sure they very much don't want to decentralize this.
I agree with your general point though, I'm very much a shell power user but I seldom use these tools because they don't seem particularly more efficient than just using the web browser in my experience. As you point out the power of the shell is to combine commands. If I just want shortcuts to list various attributes of the project I can do that with bookmark keywords in firefox for instance.
And of course these reasons are poor and hide the fact that with systems like Github (Gitlab and Bitbucket are the same), issue tracking and thelike are locked in. I only know the wiki which can be accessed as git repository (at least in Gitlab and Github). Which other Github "collections" are exposed as git repository?
"pr checkout" is the only command that seems truly useful and a time saver to me.
The best you can hope for is to make the issues readily exportable in a standard CSV format. Does it already do this?
The optimist would say limiting contributions to issues on web platform made the formatting ( markdown ) consistent. So that linking back to issues and commits was more standard, and therefore made Github Issues a nice tool to use over the competition at the time.
I love the command line too, and I get what you're saying, but why don't you just use their API?
Tell me what you think: http://9ol.es/pty.txt
this shows how good this language is
dotnet team at microsoft needs to wake up, they are soon going to be extinct