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.
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.
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...
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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 :)
> 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.
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.
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.
>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 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 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 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
> 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.
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.
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.
I wish some people at github would address the bad mobile version of their website. It's impossible to do anything done with the current mobile UI without going through the desktop version:
- see the language stats for this repo
- see commit history in one tap
- read the full readme
- see all files at top level
- etc.
If you're already hard at work on this, thanks in advance.
I think they are going to avoid any web mobile changes while they are building and promoting their mobile app, which is still in beta.
And honestly, this official app personally feels that it's even worse to navigate. Hard to navigate to your most recent repos, reading/following issues/PRs is terrible (a good 1/6th of my screen is covered by a tab in the bottom corner that I accidentally open a lot of the time when scrolling), no CI information, can't differentiate what's new and old discussion when opening a notification, can't check other branches, can't generate tokens (very useful when commiting from someone else's machine if you have 2FA), and in general it prioritizes elements without a clear reason, like the "subscribe"/"unsubscribe" button for repos.
I currently still prefer the Fasthub app for now. It still doesn't have all features above or from the web version, and it's not updated often since the app is being refactored entirely, but it's open source and it has a decent UI/UX. Definitely better than the beta official app.
> I think they are going to avoid any web mobile changes while they are building and promoting their mobile app, which is still in beta.
In theory, I would prefer a native mobile app to a web page, for a number of reasons. First of all, a web page is ideally static, with no JavaScript and no interactivity other than POST submission — a native app provides a developer the opportunity to add behaviour and interactivity appropriately. Second, a native app can be customised to the particular needs of working on a mobile device.
But in practice I avoid apps like the plague. I no longer trust that Android will properly shield one app's data from other apps: for all I know the GitHub app will upload all of my photos and text files to Microsoft for analysis. And then so many mobile apps aren't even native mobile: they are just wrapped web pages, in which case one gets the worst of both worlds: a potentially-insecure app which can break the sandbox, and a non-native web-page interface.
I used to be really excited about smart phones, but now all I really want is something with a web browser, phone calls, Signal and offline maps.
I upvoted you, but your comment is a bit misguided re: Android, especially for HN:
- if an app has access to your photos and you didn't approve so, it's a bug. Even worse, it's a security issue and you could probably collect a nice $10k to $30k bounty.
- apps that are just web pages are bad, yes but not for the reasons you underlined.
- anything that breaks the sandbox is a security issue. Nowadays it's pretty rare, too.
- if an app asks for access to your files and can't work without it, it's a badly designed app and you'd be right to complain. IMHO this is an issue that should be addressed at two levels: 1/ the OS should be able to generate fake data to let old apps work. 2/ any newly released app that tries to work around this should be banned from stores.
And yes, we're also definitely investing in the mobile app as well and the reception from the beta has been really positive so I'm excited for when we're able to roll it out to everyone.
I've heard of the app, and it's great news. But I feel that with just a little push (well, not so little, but small at Github scale), the mobile website could be so much better, and everyone would benefit from it without installing an app (although with an Instant App one could have the best of both worlds… but just on Android).
The demo of Emily and Jon's work shown by Nat is great news and I hope it continues forward.
Is there any way to get access to the beta on Android? I use GitHub quite heavily, and would be really interested in having an app and giving you feedback.
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.
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.
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).
> 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.
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.
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.
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. :)
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.
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.
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.
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.
> 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>`
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.
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.
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.
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.
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.
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.
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.
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.
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.
So is this like an improved version of git with an easier command line syntax?
As in, can you use it for local gittering, or does it really require a connection to github all the time?
Because I don't feel good about this tool if it's basically another trick at lock-in. Git the versioning system is currently pretty open; You can use your own local repos, host on gitlab or github or your own server, and you really do roughly get the same experience from the command line.
Like, is this going to prompt me to host my local git repos on github? Not whether it can, of course it can, will it nag me?
People used to call these worries FUD but they also put ads in the start menu and turned telemetry up to 11, for an OS. I think current day it's a legitimate worry to consider. I haven't really had the misfortune of having to deal with such attitude towards users on the command line. But we'll see.
Or do they see "developers" as an audience to be treated differently than "end users".
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.
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.)
I personally use the git CLI for my day to day work needs, I think this was so unnecessary considering there are so many other things that Github could focus on. Microsoft is once again ignoring the mobile market, shittè mobile app, shittè mobile website, but hey, a redundant CLI FTW
/bin/xdg-open: line 881: www-browser: command not found
/bin/xdg-open: line 881: links2: command not found
^C
1) I would have expected it to be able to work with the installed ssh keys used with the associated repo, but no luck :-(
2) RPM is broken, as it does not include any dependencies, and
3) even after install links, it fails with:
[warn] Epoll ADD(1) on fd 0 failed. Old events were 0; read change was 1 (add); write change was 0 (none); close change was 0 (none): Operation not permitted
ERROR: event_add failed: Operation not permitted at select.c:415, handle 0
4) I don't think they're gonna be handling 2FA :-/
Now open source GitHub! It is such a hypocritical stance to talk about how great FLOSS is while at the same time not producing the product itself as FLOSS.
Command line features I want for a hosted RCS/VCS: multi-repo add/remove user (support hire/fire employees), CI/CD features (set/check/pre-commit enforce tests and metrics, view state, get/set callbacks), create/config new repos.
The example commands shown support automatic creation of issues which is OK for CI/CD, but PRs are not something we use or care about. I understand it from marketing as a 'makes us different to raw git' sorta differentiating feature, but it's just not part of many company's workflow. I love and miss from previous Gitlab repos strong pre-commit hooks and being able to reject commits that breach policy or break tests. Without this CI/CD needlessly chokes on issues, state and manual process.
looking more for an administrative CLI for Github, rather than the usual "Github user" experience
Yes. Because I already have git, which by definition already does 99% of what I need as a user. Issues + remote repo admin + CI/CD are the exceptions.
What do you use instead of PRs?
Direct commit with no branching. IMHO PRs are an arguable misfeature of hosted RCS/VCS to keep people on those platforms. We have a high proportion of non software development projects/users.
Issues, CI/CD, and code review are a huge part of the development process that git does not do.
Committing directly might work for a small team, but I can't imagine that scales.
I suppose we want fundamentally different things here, and sadly for you, I don't think you're a large enough portion of the audience that GitHub will ever create the tool you need.
Their APIs are open, though -- you can probably make one yourself.
No, I am actually the majority of the potential market and future growth for hosted RCS/VCS firms: a tech company with many non-tech employees that wants to utilize RCS/VCS to formalize internal process across disciplines.
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. :)
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.
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.
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.
