Desktop: GitHub Desktop for Linux?

[hmtxz]

Updating this issue with response from @billygriffin from the GitHub Desktop team (updated early 2020):

We have no immediate plans to support an official Linux version, but we continue to evaluate it alongside our other priorities and we know it's important to many people out there. I also know "maybe someday" is a disappointing response and I apologize for that. We're enormously grateful that @shiftkey has built a fork (https://github.com/shiftkey/desktop) and that many people are using that successfully, but @shiftkey is only one person and I hope people will understand that he's not always able to keep it entirely up to date with the official version.

I assure you that if/when we're able to commit to supporting a Linux version, we'll update this issue accordingly, and I appreciate your ask for a more "official" answer.

I'd also ask that others please refrain from responding to this issue with "when though?", "I want this too", or similar responses. Thanks!

---

Original issue content:

Please make Github Desktop available for linux user 😃

Update : There is a fork with prebuilt Linux binaries by @shiftkey here https://github.com/shiftkey/desktop

[shiftkey]

@hamaminatu this is an excellent question!

Currently our focus is on catching up to feature parity with the classic Desktop apps, and getting what we've built battle-tested, so I don't think this will be on our radar before we hit 1.0.

However I'm not aware of any current technical blockers for supporting Electron on Linux distros:

• dugite-native - the Git package we use in Desktop - has been tested on recent Ubuntu and Fedora distros, and the Atom team are using it
• Electron itself is built on Ubuntu 12.04 - I know other tools like VSCode support a bunch of distros, but maybe there's gaps in the official support for other platforms that we need to address
• there's various Electron API differences - both in availability and behaviour - between macOS, Windows and Linux. For an example, read the BrowserWindow docs to see just how many differences are identified. We'd already do work differentiating between macOS and Windows in areas of the app - this is more work we need to build in and test.
• what platform resources are there for the various Linux window managers that are available? We like to adhere to the macOS Human Interface Guidelines and the Windows Design Guidelines as much as possible.

We want to ensure a Linux version has the same high standard of quality as the other platforms we support, and given our lack of in-house expertise with the Linux ecosystem we'd love to get the community involved with this effort. So if you care to help us with knowledge, platform experience or testing, please upvote this issue or comment with how you can help!

We can also open in the interim to lay this groundwork, like #273, so we can steadily move towards this goal.

[cruzerld]

I'm a Linux / Windows / Mac desktop dev and i have some expertise in a few different ways of setting up apt and rpm repos. I've set some up manually on S3 and have used Artifactory to host repos as well. I feel like most node / electron tools pretty much stopped at building the .deb and .rpm so if interested maybe I can build a package or two to help out there? I've also built an .arch package in the past but that was a while back.

[ziggy42]

For the packaging part, you should also consider appimages, snaps or flatpaks to support multiple distributions with a single package.

[introwit]

Have used the GitHub desktop app for windows for quite a long time before switching to Ubuntu this year, so I could help with testing it out on Linux and give my feedback whether it's the same experience and how the app performance is compared to the other platform versions.

[shiftkey]

Tagging this as future-work as our 1.0 work and stabilization is the current focus.

[hanjiexi]

what platform resources are there for the various Linux window managers that are available? We like to adhere to the macOS Human Interface Guidelines and the Windows Design Guidelines as much as possible.

@shiftkey

GNOME HIG: https://developer.gnome.org/hig/stable/
KDE HIG: https://community.kde.org/KDE_Visual_Design_Group/HIG

Electron-based apps tend to work the same on all desktops, but if you do want to know where to focus your efforts, I suggest making sure it works great on GNOME, since that is the default (or will be soon) for the two most popular and commercially-supported distributions (Ubuntu and Fedora) as well as for Debian.

[picandocodigo]

I got it working on my system! (Debian GNU/Linux 9) I have never used Electron before and have very little experience with Node, so it took some workarounds. You can check the work in progress in my fork. There's still lots of stuff to do but it works!

[prijindal]

@picandocodigo
Works on Arch linux (4.9.27-1) with GNOME (3.24.2)

[lilianmoraru]

People seem to report of it working.
Linux is open-source, one can easily test the app in a VM(and Travis is already set).
Seems just like an extended "thank you" to Linus Torvalds.

[z0al]

I'm a Ubuntu user and would love you contribute and test the Linux version. At least I can then remove the slow Win10 (VM) I currently use for contribution :sweat_smile:

[prajapati-parth]

For the packaging part, you should also consider appimages, snaps or flatpaks to support multiple distributions with a single package.

@ziggy42 VS Code is open sourced. We could use that for packing reference.

Electron-based apps tend to work the same on all desktops

@hanjiexi Agreed. Also GitKraken is an excellent example for this.

[ziggy42]

@prajapati-parth I'm fine with .deb and .rpm (I only use Ubuntu and Fedora so I'm covered :smile: ), but there are also examples using Appimages, like Microsoft BotFramework-Emulator.

Anyway, as long as you don't only ship debs, I'm fine :ok_hand:

[ankibalyan]

I'm also a ubuntu user, would love to see github on linux, also I'd like to go from 0.1 stage itself for testing.

[gengjiawen]

I have use travis ci to build github linux client, anyone interested can give it a try. Binary download : https://github.com/gengjiawen/desktop/releases.

[hron84]

@gengjiawen the 0.5.4 release has no binary. What is the difference between alpha2 and final 0.5.4?

[hron84]

Also, I wanna state here 0.5.4-alpha2 is works like a charm. I just downloaded yesterday, but can't wait to be GitHub officially on Linux.

[gengjiawen]

@hron84 Use the alpha version, since the linux version has not been fully tested. The 0.5.4 tag is not what i want, but github dont allow you to delete a tag release, just ignore it.
And also glad to hear it works.

[hron84]

@gengjiawen OK, thanks for the reply. Random tips: ship an icon with deb-rpm files, and also add a Category field to the .desktop file. If you can point me to the linux build script, I can make you few modifications to ship better packages later.

[gengjiawen]

You can fork my repo and change it (branch ci_build). The config file is the root package.json. And if you want other linux distro, you can config this file too. I hope Github desktop team will consider switch to electron builder.Because with electron builder we can use travis ci and appveyor to build multi platform binary.
Have fun :)

[hron84]

@gengjiawen next week i will check it out.

[hmtxz]

hope it will available in AUR too 😄

[ankibalyan]

@gengjiawen tried 0.5.4 with source compilation, its working fine, will keep on testing.

[kleinen]

Seems I am getting hung up on 2FA code entry when connecting to Github Enterprise. Works on Windows/Mac just fine, but Linux seems to never finish verifying the code. If anyone wants any data or info, let me know what you want me to gather (and how to get it since I am not experienced in the ways of Electron/Node).

[kleinen]

I would also be a huge proponent for this feature as an enterprise customer that would like to have this for 300+ people. I've been working my account rep to see if they can help drive the priority of this. 👍

[lypborges]

@picandocodigo I tried your fork last night. But didn't work. I think it's because I'm using node x64 arch or maybe I'm missing something.

 lypborges  ~/Develop/GitHub/desktop  master  npm start                                                ✓  1732  22:30:14 
npm WARN lifecycle The node binary used for scripts is /home/lypborges/.asdf/shims/node but npm is using /home/lypborges/.asdf/installs/nodejs/7.10.0/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> @ start /home/lypborges/Develop/GitHub/desktop
> cross-env NODE_ENV=development node script/start

I dunno how to run on x64 :(

npm ERR! Linux 4.8.0-52-generic
npm ERR! argv "/home/lypborges/.asdf/installs/nodejs/7.10.0/bin/node" "/home/lypborges/.asdf/installs/nodejs/7.10.0/bin/npm" "start"
npm ERR! node v7.10.0
npm ERR! npm  v4.2.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ start: `cross-env NODE_ENV=development node script/start`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @ start script 'cross-env NODE_ENV=development node script/start'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the  package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     cross-env NODE_ENV=development node script/start
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs 
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls 
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:

I'll keep trying, but If you have any tips. Tks :rocket: :penguin:

[shiftkey]

Seems I am getting hung up on 2FA code entry when connecting to Github Enterprise.

@kleinen this might be #1628 - could you confirm which version of GitHub Enterprise you are connecting to?

[kleinen]

My company recently upgraded to v2.9.

[shiftkey]

@kleinen please open a new issue with as much information as you can provide so we can investigate further...

[picandocodigo]

@lypborges I am running x64 too. I used to see that same error at first but solved it somehow along the way. Try updating the branch and running npm install (I guess this is necessary to update any libs from commits in master), npm run build:dev and then npm start again, see if that solves the problem for you?

By the way, I'm constantly updating my linux branch to keep it in sync with master.

[lypborges]

@picandocodigo I was running on the wrong branch...uihauihaui. Tks.

[kleinen]

@shiftkey Done! https://github.com/desktop/desktop/issues/1753

[rlabrecque]

I don't use linux much but should g++-4.8 gcc-4.8 be replaced with build-essential?

[hron84]

@kleinen Alpha works on Ubuntu 16.04.2, even with MFA

[probonopd]

@gengjiawen thanks for the AppImage, works for me on Ubuntu 16.04.
https://github.com/gengjiawen/desktop/releases

[liberodark]

Please make a linux version !

[probonopd]

Providing an AppImage would have, among others, these advantages:

• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[solinium]

Thanks @gengjiawen
Works for me on Ubuntu 17.04 on XFCE
EDIT: pushing and pulling doesn't work by default, compiling it with libcurl4-openssl-dev it seems will fix the problem

[hron84]

@probonopd There is no need to advertise AppImage. GitHub does packaging on its own and I really hope they employ quite good engineers and developers to make a right decision how and where they publish their software. Also, a GitHub issue is not a right place to advertise your project.

Even if you had good intentions with that comment, it bothers others and also very offtopic relating to this issue because at this time the Linux version of this software is simply non-existent, thus there is nothing to package. So please, skip these comments next time. Thanks.

[probonopd]

Even if you had good intentions with that comment, it bothers others and also very offtopic relating to this issue because at this time the Linux version of this software is simply non-existent, thus there is nothing to package.

Sorry @hron84 but I have to disagree. In fact @gengjiawen has shown that it is entirely feasible to produce a working Github Desktop for Linux. He even provides a __working Linux AppImage for download__ on https://github.com/gengjiawen/desktop/releases (albeit not yet size-optimized).

GitHub does packaging on its own and I really hope they employ quite good engineers and developers to make a right decision how and where they publish their software.

I hope that they have a look on the work @gengjiawen has done.

[hron84]

Yeah, @gengjiawen working on a Linux version of GitHub Linux, but this issue is at @github's own issue tracker and not in @gengjiawen's one. Your comment is still offtopic here. If you want to suggest something to @gengjiawen, you can simply try to contact him/her. GitHub issues are not a forum topics and not a messaging platforms. All developers here try to keep the topic directly related to the issue. Suggesting a packaging platform is OK if you just say "Hey, use AppImage, here's a link to it", but writing a marketing-smelling comment to an issue is nothing but advertising what is - I think - not what are GitHub issues are for. I hope everything you wrote here can be found on the AppImage's homepage, thus needless to copy-paste its content.

[probonopd]

I am directly staying on topic "Please make Github Desktop available for linux user", suggesting a potential solution, and gave reasons why I think this would be a good idea.

[greggwon]

I guess I would ask a different question and point in a different direction. Why hasn't Java been considered as a much more portable way to get a great desktop app working across a wide range of environments?

[kleinen]

@greggwon I very much find the java subject interesting and conversation-worthy, but maybe that would be a good point to break that out into another issue asking for a java-based client. Then we can discuss that as its a larger scope than just "need to get electron's support for linux to work".

[joshaber]

We're happy to review and accept pull requests adding Linux support 😄 There haven't been any that I've seen yet.

[shiftkey]

We've also been working on issues with the dependencies that Desktop needs for Linux support:

• improving the packaging size of dugite-native: https://github.com/desktop/dugite-native/pull/51
• using dugite with different Electron setups (with some great help from @gengjiawen): https://github.com/desktop/dugite/issues/96

[picandocodigo]

@brunofin They've already mentioned they don't have in-house expertise, and from a business point of view it probably doesn't make sense for them to spend resources for Linux. As a Linux user myself I'm not even using the app, I feel comfortable with the command line. But it'll be nice to have the tool available on Linux.

I would suggest those of us who've been tinkering with it to join forces. We know the app runs, but following steps could be:

1 - Make sure we make the tests running properly. Unit tests pass on my setup, but integration tests fail.
2 - Have a working Travis build for Linux.
I'd say these two would be the first things to tackle before thinking of packaging.

Once we get that working we can make a Pull Request. As they mentioned, we haven't really submitted Pull Requests with our stuff, and they're open to supporting Linux. So don't get mad at them, let's all just work together to get this moving forward :smile:

[shiftkey]

@picandocodigo

1 - Make sure we make the tests running properly. Unit tests pass on my setup, but integration tests fail.
2 - Have a working Travis build for Linux.

I have a branch lying around that I started as a hack project that takes care of both of these: https://github.com/shiftkey/desktop/pull/1. This only addresses the build and test steps.

I think the packaging changes that are necessary are the biggest bit of work that we need to size up (electron-packager has limited support for Windows and Linux packaging formats, and I know @gengjiawen has been looking at electron-builder which we might need to migrate over to as part of supporting this.

[joshaber]

@brunofin Please keep in mind we're all just people here, doing our best. There's no need to antagonize.

[ptomato]

Here's a pull request for Linux support: https://github.com/desktop/desktop/pull/2271

I'm doing this with the end goal in mind of submitting a recipe to @flathub in order to make the app available as a Flatpak package. Here's my initial attempt at packaging it: https://github.com/endlessm/github-desktop-flatpak/pull/1
In order to build properly on Flathub I'll need to freeze all the dependencies with Yarn or something like that, but I haven't gotten around to that yet.

[gengjiawen]

Inspired by @ptomato , I created a pr https://github.com/desktop/desktop/pull/2300 too.

[DaniellMesquita]

The GitHub desktop site is open-source?
Also, I agree about porting it to Linux. I know Linux users like code/CLI, but lets incentive Windows users to use Linux.

[shiftkey]

The GitHub desktop site is open-source?

No. See #2101 for that discussion.

[Aashit-Sharma]

@gengjiawen Works on my precious Linux Mint !
Many thanks to you ! :smile:

[shiftkey]

@rogersachan we're working through integrating these changes into the repository - see #2300 for an example of this work.

[rvdende]

cant wait for linux .deb on ubuntu!

[gluons]

@fluentart And PPA. 😄

[AdrianDroid]

+1
cant wait for .deb

[ziggy42]

I'm sure we all agree a cross-distro solution would be better :smile:

[probonopd]

@gengjiawen has a working one since May 18 @ziggy42

[prajapati-parth]

I don't understand why a linux version is required. I just use VSCode to manage git.

[Ortham]

@prajapati-parth: And you can keep doing so, but other people have different preferences, and choice can be a wonderful thing.

[hron84]

@prajapati-parth VSCode is a wonderful app, if you use it as your main IDE. However, if you mostly work with a different IDE with better support for your programming language but worse Git support, using VScode just for git commiting is like using a microscope just for lit a cigarette.

[ziggy42]

@probonopd I've tried it, but I'll use Github desktop at work only when it'll be officially available for Linux

[cbluth]

I am a Linux user, and I prefer either appimage/flatpak or just a simple tar.gz with binaries.

[fevangelou]

Let's see an official release first in any form and we can "argue about the
color" later. ;)

On Sep 19, 2017 9:11 PM, "cbluth" [e-mail] wrote:

I am a Linux user, and I prefer either appimage/flatpak or just a simple
tar.gz with binaries.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/desktop/desktop/issues/1525#issuecomment-330624464,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPdG6w2jvDbSrTpLwFjsrBE71VTdHV8ks5skAO7gaJpZM4NdOxw
.

[jacmoe]

Since I can't use deb or rpm I prefer a "color" that fits all :)

[shiftkey]

I've been having some troubles running my Linux branch since we upgrade to Electron 1.7.5 in #2582 - app refuses to launch, not seeing any errors on the terminal.

Has anyone else seen this? cc @gengjiawen

[gengjiawen]

@shiftkey Yes, I notice this too, but I have not got time to figure it why.

[shiftkey]

@gengjiawen thanks for confirming. Once this release settles down I'll trace it to whether it's something in Electron, a new dependency that needs to be installed, or something in how Desktop is being packaged and launched.

[gengjiawen]

I tried Windows and Mac too, they works fine. Though integration test failed on travis ci.

[gengjiawen]

@shiftkey Maybe a bug in code, I replaced the main.js with another project's, the electron window occurred.

Update:

1. change show: false to show: true in app/src/main-process/app-window.ts, the window occurred.
   Then in developer tool show the following error

Uncaught (in promise) Platform not currently supported for resolving editors: linux

2.
I found a Fix: change code app/src/lib/dispatcher/app-store.ts, looks some compatibility issue introduced in 9b0c2e10e2681736aa9f9e2edbd57b6071c2955b

try {
  const editors = await getAvailableEditors()
  if (editors.length) {
    const value = editors[0].editor
    // store this value to avoid the lookup next time
    localStorage.setItem(externalEditorKey, value)
    return value
  }
} catch (e) {
  console.log(e)
}

1. We may need to do more to avoid such issue. Any special reason show: false is default option.

[joshaber]

@goldenfreemanchina part of your comment was deleted as a violation of the Desktop Code of Conduct as it is unprofessional conduct. You may consider this an official warning.

[KristijanZic]

Why don't you get in touch with the Ubuntu Snappy team? I'm sure they would be willing to assist you in packaging github-desktop as a snap package. You should open a topic on the forums at https://snapcraft.io/

[shiftkey]

Nice spot @gengjiawen!

Any special reason show: false is default option.

I think this is related to showing the main window _after_ the content has been rendered (rather than showing a blank window initially): https://github.com/desktop/desktop/commit/2a591c80604ec158c8ac543fe969b6bff6ccd20d

That fits with the "cannot resolve editors" error you also found, as I think that code path is part of setting up the initial state, which would then prevent the renderer from raising the show-main-window event to then display itself.

Let's see if I can put together a fix for that to return an empty list rather than erroring...

EDIT: #2807 should get this back to a happy place

[zackeezy]

@picandocodigo I am trying to run your branch in Linux Mint 18.1 but it keeps getting stuck at

npm ERR! @ compile:tslint: `tsc -p tslint-rules`
npm ERR! Exit status 2

And when I tried to run npm run build:dev it errored out at WEBPACK] Errors building ask-pass.js and warned of a lot of generics being used wrong.

[picandocodigo]

@zackeezy my branch is way behind master and lots has changed since then. The build is set up on Travis for Linux (#2808), so I guess there's better support in the latest code. I'll try to update my branch as soon as possible. The branch might not even be necessary anymore, we'll see.

[zackeezy]

@picandocodigo So could i try to build this branch for linux, theoretically?

[shiftkey]

@zackeezy @picandocodigo please try the latest master branch here and these instructions to test out the dev version:

npm install
npm run build:dev
npm start

If you are encountering a specific error, I can probably help with getting to the bottom of that.

[zackeezy]

Wow it worked. It opened with the developer tools open for some reason, but yea, it works. My only question now is how to have it runnable from the start menu.

[shiftkey]

@zackeezy that's the packaging step which we haven't gotten to yet. Some progress is underway in #2300 but I need to get back and update that with some current thoughts...

[zackeezy]

@shiftkey I'm just happy I have the gui version on my computer now. I use a bash script to run Minecraft and several other programs so I won't be too upset if I have to set one up for Github Desktop, too.

[cbluth]

RE: https://github.com/desktop/desktop/issues/1525#issuecomment-332676885
@shiftkey those instructions fail if the .git directory is missing (downloaded via master.zip).

[zackeezy]

@cbluth I cloned the repo from command line. Doing so and then doing what he said makes it work.

[shiftkey]

@cbluth that's likely due to us embedding the SHA in the webpack configuration - we recommend working from a clone of the repository.

[j-f1]

Maybe that should use git rev-parse HEAD instead — I had trouble building when I checked out a copy of the repo in a git worktree.

[shiftkey]

@j-f1 it is using that, except when we can't:

https://github.com/desktop/desktop/blob/0a90898a65805de2001736049efbb1287e94de69/script/dist-info.js#L199-L208

Open to suggestions or scenarios we haven't yet encountered in a new tech-debt issue.

[probonopd]

@zackeezy that's the packaging step which we haven't gotten to yet.

@shiftkey: @gengjiawen has a working automated packaging process for making AppImages since May 18, perhaps you might consider upstreaming this.

[shiftkey]

@probonopd please see #2300 which is our ongoing discussion about this

[qrkourier]

I had to do apt install libsecret-1-dev before npm install on Ubuntu Zesty 17.04 because

Package libsecret-1 was not found in the pkg-config search path.                                           
Perhaps you should add the directory containing `libsecret-1.pc'                             
to the PKG_CONFIG_PATH environment variable                                                                
No package 'libsecret-1' found                                          
gyp: Call to 'pkg-config --libs-only-l libsecret-1' returned exit status 1 while in binding.gyp. while trying to load binding.gyp

I also nuked and re-cloned the repo because there were some errors that I suspect were caused by building modules with different versions of Node. It worked with v8.6.0.

[Croydon]

I also had to install libsecret and a few others libraries on Fedora+KDE.

[shiftkey]

If someone wants to add the packages they install for their distribution so we can improve the setup documentation I'd be more than happy to collaborate and review.

[mikelpint]

I have written one for the AUR long time ago.

[appelgriebsch]

I did a recent build (v1.0.3) on my Fedora 26 VM and packaged it as RPM and DEB. Could test the RPM already and it worked fine. Feel free to use it (https://github.com/appelgriebsch/dotFiles/releases/tag/0.1.0)

[Deams51]

@shiftkey Made a PR for Ubuntu 16.04 packages #3157

[ghost]

Github Desktop Worked On Backbox5.1 (ubuntu 16.4) THANKS!

[beruic]

@Deams51 Any idea off when to expect it from official channels?

[ilhamdoanggg]

linux no needed it

[nkkollaw]

@appelgriebsch: I've installed it on elementary OS, and it does work, but it for some reason cannot get window controls correctly (maximize button is missing), and the window cannot be resized vertically.

Awesome work, don't get me wrong. Just thought I'd leave some feedback.

A snap would be pretty nice!

[Roychenlei]

i need linux

[nkkollaw]

@Roychenlei linux no needed it

[Xalalau]

+1 for Linux

[RevoluPowered]

I need it too. Snapd or flatpak

[Serkan-devel]

Appimage support when?

[qaamal]

+1

[vitalkanev]

I might want to get PPA from Launchpad somewhere.

[ptomato]

Please don't post "+1" or "When is it happening" comments. It creates noise for everyone else and makes the real discussion harder to follow. You can subscribe to the issue to receive notifications, or add a :+1: reaction at the top of the page to show that you want this.

[mitar]

I tested this out yesterday and it works pretty well, but there are some simple issues.

I used update-electron-builder-linux branch (#3407) and followed setup process here to prepare the environment. I used Docker and ubuntu:trusty base image (to use the same as it is used in TravisCI) to do all the work. I tested resulted packages on Ubuntu 17.10.

So after installing dependencies, I called yarn run package to get packages built into dist subdirectory. I found three issues:

• appimage, it does not start: #3425
• Debian package:
  
  
  
  • it has confusing package name, just desktop: #3424
  
  
  • it does not work because of a broken symlink: #3426
  
  

So after I fixed the broken symlink, GitHub Desktop started working for me through Debian package.

Contributions to fix all of that are welcome, if anyone is familiar how to do so.

[RevoluPowered]

Cool, I might contribute by uploading it to snapd as 'alpha'

@mitar I will also test this on Fedora and confirm it works. Do you use snapd? If so after I bundle it can you help test the snap?

[mitar]

For snapd, ideally, we should add it so that it is generated with yarn packages as well. I use Ubuntu 17.10, which supports snaps, so I can test it.

[TingPing]

I will add a Flatpak to Flathub the second an official release happens.

[ziggy42]

@TingPing do they only allow officially supported apps?

[vitalkanev]

I could create PPA via Launchpad.

[RevoluPowered]

okay, I'll see if I get time today to add support using 'yarn packages', if not I will have time tomorrow probably.

Working on a game at the moment so not had huge amounts of free time, but getting this running on Linux would be handy as I don't like git cola any more.

[shiftkey]

First off, thanks for everyone who has commented here and gotten involved with getting Desktop working on Linux! I wanted to take this moment to revisit this thread and then sketch out a way forward so we can make our Linux support better!

Feedback Themes

Looking over the current feedback here, it falls into a few distinct themes. I'll summarize them here and address them from the perspective of the core team.

• "I want a Linux version"

It's great to hear this passion and excitement, but without tangible feedback or actionable tasks we're a bit in the dark. Also, please don't +1 this thread - use the reactions!

• "I was able to run it up on XYZ distro but encountered a problem"

These sorts of things are great, because it gives us details about what you're using and what the issue is - whether it's a blocker or polish, whether its something we can fix or we can talk to the Electron team about. The more details included, the better!

• "I've made package of Desktop available for XYZ distro"

This is also great to hear! We're a small team trying to work on quality and feature stuff at the moment, so any people who can step up and help out are more than welcome. If you're happy to manage publishing updates when we make new releases available, feel free to submit a PR so we can promote it in this repository. This PR and the related issue is a good example.

• "I want a Linux build in XYZ package format"

We're currently leveraging electron-builder to generate packaged versions of Desktop, and the list of formats is large - formats not in that list will require contributions to electron-builder, and the Desktop team does not have the bandwidth to do this for the foreseeable future.

If you're interested in this space, there's a guide to getting Desktop up and running locally with instructions that cover some mainstream distributions.

The Next Steps

So how can we leverage the interest and passion here to move this issue along? Here's what I've been busy with lately...

Better Usage of electron-builder

Up until recently we had the ability to generate packages for RPM, DEB and AppImage using simple wrappers on top of electron-builder, but these needed some work:

• installers don't work as expected - e.g #3425, #3426
• installers aren't configured as expected - e.g. #3424
• support for other package formats

I've merged #3563 to get us back using electron-builder for our Linux package targets - this gives us access to everything that electron-builder supports for whatever targets we end up choosing.

Release Candidates

Ensuring we are generating quality installers requires testing time, and not everyone has the time to keep up with our development, let alone create their own installers and run them. So what if we used my fork (shiftkey/desktop) on GitHub and added new builds whenever new tags were pushed to the main repository?

Using tagged builds helps us correlate the source for a build for any bugs reported, without having to worry about how someone built the code and that they used the right source.

We just published the 1.0.11 update today for macOS and Windows, and as an early Christmas present to you all I've published the first release candidate here for you to try out.

What We Need From You

If you are interested in these release candidates: watch shiftkey/desktop as these builds are tagged and published. This will give me an idea of how many people are actively interested in helping out with this effort, beyond those who are just upvoting this issue out of interest.

If you encounter an issue with these release candidate installers, report an issue to my fork shiftkey/desktop with as much detail as possible. Do not submit an issue to the main repository. Any issues filed in the main repository will be closed with a note to file them in the right location.

There are a few reasons for this:

• I'm probably the most experienced one with these sorts of issues currently, and have a couple of setups to help with testing. Keeping this out of the main repository means the rest of the core team can focus on their priorities in the short-term, rather than having to triage these as part of their normal work.
• Having these issues in one spot means I can identify just how much work we have to do, and triage them whenever I have bandwidth. I can then organize getting things upstreamed as they're ready, and possibly ship interim release candidates over in the fork.
• By keeping this work in my fork, we avoid any potential confusion when we figure out what our "official support" story looks like.

If you are building from source and something isn't working as you expected, have a read of the documentation for the tools we are using:

• electron-packager options
• electron-builder linux configuration options

The right setting is probably something we've overlooked, hiding in one of those two places. I'll write up some documentation to help others with testing installers locally, to make it easier for people to dive into this.

If you think you've found a solution, please submit a PR to shiftkey/desktop explaining the change and what it fixes. If you're not quite sure, open an issue on the shiftkey/desktop fork explaining what you've found and where you think the problem lies. Maybe someone else has insight into the issue.

For any other questions or suggestions related to GitHub Desktop & Linux, please open an issue over on shiftkey/desktop. This will help me track feedback better and discuss things in more detail. You can continue to use this thread for general discussions, but the more interesting stuff should be over on shiftkey/desktop.

Closing Remarks

We haven't committed to too much work here, or been too specific with timelines, because we don't want to mess this up. The team here are sticklers for quality (and I say despite being the one who has broken the Linux build by accident) and we need your engagement and experience here to ensure we do this right.

With Christmas fast approaching, the team will be taking some time off over the next few weeks. We're gathering in January to reflect on the last year and plan for the year ahead, so the input from that will affect where we focus our efforts around this area in the short-term.

[SirFaenor]

AppImage works for me on Opensuse Leap 42.3 with this little hack:
ln -s /usr/lib64/libcurl.so.4 /usr/lib64/libcurl-gnutls.so.4
otherwise is reporting an error about failing to load shared libraries.
Thanks!!

[shiftkey]

@SirFaenor is this related to Git operations? I think this is https://github.com/desktop/dugite-native/issues/42 which is an ongoing discussion about how to statically compile Git.

[SirFaenor]

@shiftkey I am not a os guru but I suppose it is. I can easily reproduce the error by removing the symlink:
/tmp/.mount_GitHubVyFZN6/app/resources/app/git/libexec/git-core/git-remote-https: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
so it seems related to git-remote-https.
Sorry I didn't notice the issue you referenced.

[wboswall]

Why not just clone the windows version of Github desktop and make it available for Linux distributions? That would solve the problem.

[sersorrel]

@wboswall That's exactly what's happening; feel free to peruse the comment by shiftkey located four comments above yours.

[wboswall]

@anowlcalledjosh That's good to hear but why is it taking so long for it to be released?

[sersorrel]

@wboswall Take a look at the comment I mentioned above, look at the current issues, and read this comment too.

[atherdon]

EN: Make Linux git GUI great again!
RU: ну пазяяя, ну оч хочется на линухе кнопочки жать((((((

UPD installed beta. Can login. Will test it right now. @shiftkey you and whole team rocks!

[holms]

So where we in here? I mean Arch linux has an option to build Github Desktop from NPM what's the problem to craft deb and rhel packages and roll it out officially? Your app is crossplatform from the start right?

[wboswall]

@anowlcalledjosh Okay thank you for info but the comment didn't pertain to me at all. I can't wait to see the debian version of GitHub.

[ptomato]

@wboswall It pertained to you in the following way:

It's great to hear this passion and excitement, but without tangible feedback or actionable tasks we're a bit in the dark. Also, please don't +1 this thread - use the reactions!

Please don't post "+1" or "When is it happening" comments. It creates noise for everyone else and makes the real discussion harder to follow. You can subscribe to the issue to receive notifications, or add a +1 reaction at the top of the page to show that you want this.

[shiftkey]

@wboswall @anowlcalledjosh @holms please have a read of the documentation about our Linux testing work - there are builds available for you to evaluate, and there are ways for you to provide feedback...

[git-repo-farm]

Found a windows HP laptop by the garbage dumpster and it was running win XP. Swapped to ubuntu OS and I cannot wait to test Github desktop for Linux as per the documentation above my comment >_< .

[ghost]

using manjaro here and the AUR package is broken / unsigned

[xgdgsc]

I' m on manjaro and the AUR package works well.

[adymitruk]

Anyone make a snap of it yet? (see snapcraftio on twitter)

[ghost]

@xgdgsc

[xgdgsc]

see https://aur.archlinux.org/packages/libcurl-openssl-1.0/ , gpg --recv-keys --keyserver hkp://18.9.60.141 5CC908FDB71E12C2 would work.

[Malaguth]

I'm having trouble to install libcurl-openssl-1.0, dependency for github-desktop aur.

[joaomlneto]

@Malaguth: I’d advise you to install from release rather than compiling it yourself.

https://github.com/shiftkey/desktop/releases

[davidroyo]

@joaomlneto Thank you very much man

[JaviCervera]

@joaomlneto Wow! Thanks a lot, man! Would be great to see this merged into the official repos.

[eRadical]

Works for me on Fedora 28...

I had to install yarn and then:

dnf install libsecret-devel
yarn install --force
yarn run build:prod
yarn start

[shiftkey]

@eRadical we've got a setup guide for Fedora as well as some other distros to help with getting started.

[annymosse]

Please make a linux version !

[JaviCervera]

There is a fork with prebuilt Linux binaries here: https://github.com/shiftkey/desktop

I am using it on Xubuntu 18.04 and it works well.

[Serkan-devel]

Maybe the link should be placed in the first post for everyone

[akalongman]

+1 for official Linux version

[Serkan-devel]

It will happen, but pls no spam anymore. There are emojis for voting now.

[davidroyo]

Well, i don't think if it will happen knowing that now we have microsoft here, microsoft should've build a VSTUDIO version for linux too, instead they built the big shit Visual Studio Code.

Why the downvotes bruh? haha

[Serkan-devel]

While the acquisition isn't good, I heard that there should be a beta version of VStudio be released on Linux.

But this thread is still only for Atom support on Linux

[chakradarraju]

+1 for linux client

[beruic]

@chakradarraju please read the last comment by @Serkan-devel

[mufumbo]

Any news on this? The electron app only purpose is to make macos users suffer? The windows improved a lot, but it's just because the old C# version sucked.

[j-f1]

@mufumbo Check out https://github.com/shiftkey/desktop.

[davidroyo]

I don't know why there are so many downvotes for the people who are supporting a linux version of github desktop

@mufumbo But it's not official, please do the favour and build an official linux version

[anaibol]

+1 for official Linux version

[j-f1]

@TheHanns There are 👎 on the 👍 comments because there’s a 👍 button on the original comment of the issue that has the same effect, but doesn’t cause many people to get notifications or make the page get any longer than it already is.

[santaclauze]

+1 linux version

[cpxPratik]

Upvote the issue on top. Time to unsubscribe from this issue and use this instead: https://tellmewhenitcloses.com/

[paletteguy]

+1 linux version

[marcus-sa]

Only solution is: Gitkraken

[KaMeHb-UA]

@marcus-sa are you sure?) How about https://github.com/shiftkey/desktop/releases, https://github.com/gengjiawen/desktop/releases and https://aur.archlinux.org/packages/github-desktop/ ?

[NatoBoram]

So I went and looked to see if there was a snap build, just in case...

$ snap search github-desktop
Name            Version  Publisher     Notes  Summary
github-desktop  1.3.4    snapcrafters  -      Extend your GitHub workflow beyond your browser with GitHub Desktop

And holy shit it's here! Let's get some info about it!

$ snap info github-desktop
name:      github-desktop
summary:   Extend your GitHub workflow beyond your browser with GitHub Desktop
publisher: Snapcrafters
contact:   https://github.com/snapcrafters/github-desktop/issues
license:   Proprietary
description: |
  Extend your GitHub workflow beyond your browser with our Desktop,
  completely redesigned with Electron. Get a unified cross-platform
  experience that's completely open source and ready to customize.
snap-id: vxuDrMy9vuqIU5Abf2MQOowf2e09tcm9
channels:                     
  stable:    –                
  candidate: –                
  beta:      –                
  edge:      1.3.4 (31) 140MB -

Okay, okay. It's the real thing. Time to install!

$ sudo snap install github-desktop
error: snap "github-desktop" is not available on stable but is available to install on the
       following channels:

       edge       snap install --edge github-desktop

       Please be mindful pre-release channels may include features not completely tested or
       implemented. Get more information with 'snap info github-desktop'.

Ah, oops. Let's try again.

$ sudo snap install github-desktop --edge
Download snap "github-desktop" (31) from channel "edge"
github-desktop (edge) 1.3.4 from Snapcrafters installed

Let's run it!

An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.267" (uid=1000 pid=21441 comm="/snap/github-desktop/31/opt/GitHubDesktop/desktop " label="snap.github-desktop.github-desktop (enforce)") interface="org.freedesktop.Secret.Service" member="OpenSession" error name="(unset)" requested_reply="0" destination=":1.20" (uid=1000 pid=1732 comm="/usr/bin/gnome-keyring-daemon --daemonize --login " label="unconfined")

And it doesn't work.

• https://github.com/snapcrafters/github-desktop/issues/9
• https://github.com/desktop/desktop/issues/5606

Edit

Thanks to https://github.com/shiftkey/desktop/issues/59#issuecomment-424110415, this problem was resolved!

sudo snap connect github-desktop:password-manager-service

[shiftkey]

@NatoBoram I've been talking with the Snap team recently about this, please keep an eye on https://github.com/shiftkey/desktop/pull/58

[danielb987]

@shiftkey : Thanks for the Linux packages!

But I have today done a new install of Debian Buster. I installed your latest GitHubDesktop-linux-amd64-1.4.0-linux3.deb and it worked fine. But when I tried to clone a repository, I got the error that git-remote-https could not found CURL_OPENSSL_3. I have libcurl4. The package libcurl3 doesn't seem to be in the debian distribution.

By doing a google search on debian libcurl3 libcurl4 , I find several pages that explains that it's impossible to have both libcurl3 and libcurl4 at the same time.

This doesn't seem to be a problem with GitHub Desktop itself, but with the version of git that is included in the GitHub Desktop Debian package.

Is there a way around this? Could I install git separately and when have GitHub Desktop use that git?

[shiftkey]

@danielb987 you can read more about this issue in https://github.com/shiftkey/desktop/issues/60 - I'm building the embedded Git on Ubuntu Trusty (to avoid linking to newer glibc APIs, but doesn't support libcurl4), so I need to figure out how to reconcile the split in dependencies between older and newer distros - that's being tracked in https://github.com/desktop/dugite-native/issues/109 so if you have any ideas please chime in there.

Is there a way around this?

I haven't found anything yet. I thought switching over to plain libcurl from libcurl-gnutls was a good idea but this libcurl3/libcurl4 split is even more annoying.

Could I install git separately and when have GitHub Desktop use that git?

This isn't supported, for reasons I've outlined here: https://github.com/desktop/desktop/issues/3435#issuecomment-347388985

[webdawg]

It would be pretty cool if a technology company that is built with a Linux back-end, would officially support Linux users that use Linux as a desktop. While the development community around Linux is great, why is there still not an official backing from GitHub on this? Could you not at least get a few interns on it?

[j-f1]

@webdawg The Linux fork is maintained by @shiftkey, a GitHub employee.

[webdawg]

@j-f1 thanks for clarifying this, and I am sorry I made a mistake

[alexanderadam]

But why does it need a fork for it at all?
This just increases the maintaining effort because patches have to be applied on two locations.
Besides from that it isn't a native application anyway, so this ticket is perfectly valid.

[probonopd]

Possibly once @shiftkey and his employer deem it ready for prime time it will be merged? One can dream...

[Daniel-McCarthy]

@alexanderadam Just for some extra information, just yesterday Shiftkey upstreamed some of the Linux specific patches to the main Desktop repository.

[alexanderadam]

Woah, @Daniel-McCarthy, awesome news! :heart_eyes:
Thank you so much @shiftkey!

[danielb987]

@shiftkey I have one small problem with the Debian package and that is the name of the package once installed. When I install the Github Desktop debian package, the name in the package manager is "desktop". This sounds like a system critical component and makes it difficult to find, for example if I need to uninstall. It would be great if the debian package had a name like "github_desktop". I know the deb file has that name, but once the package is installed, the installed package has the name "desktop".

[Croydon]

@danielb987 Open/follow Linux related issues in shiftkey's repository https://github.com/shiftkey/desktop/issues/22

[joaomlneto]

@danielb987 Linux-specific issues are being tracked in https://github.com/shiftkey/desktop .
This issue is already posted in https://github.com/shiftkey/desktop/issues/22

[shiftkey]

Alright, looks like I need to add some extra context.

This is a passion project of mine that I kick along whenever I have spare time. I've written up details about this phase of testing and I'd recommend reading that too.

But why does it need a fork for it at all?

Doing it in a fork gives me several benefits:

• we can focus on Linux testing and issues there, and let the rest of the maintainers focus on the main product
• we can experiment with patches and fixes at our own pace
• I can ship new builds out-of-band, without needing to go through reviews and merging into the main repository

This just increases the maintaining effort because patches have to be applied on two locations.

When a new release is made, I'll pull those changes into my fork, apply the current Linux-specific tweaks I'm currently testing on top of that, and publish to my fork (by pushing a tag to Travis).

Every now and again I'll co-ordinate to get patches merged upstream once I'm satisfied they're stable (so I have less to reapply after each update) but you can see what's currently different between my linux fork and the current master: https://github.com/desktop/desktop/compare/master...shiftkey:linux

Besides from that it isn't a native application anyway, so this ticket is perfectly valid.

There are Linux-specific issues that I've been working through which are independent to the core application, and are ideal to do from a fork:

• Git - we embed a version of Git into the app, and we need to ensure that works across various distros and setups
• packaging - we support a number of different formats, but there's often tweaks and improvements needed to figure out after getting it working
• updating - currently installers are published as GitHub releases - I'd love to figure out how to do better here

[alexanderadam]

Wow, @shiftkey thank you for answering in such detail!

we can focus on Linux testing and issues there, and let the rest of the maintainers focus on the main product

Well, they are focussing on Mac installations as well, right? So it seems that it isn't a platform independent build at the moment that indeed would allow to focus on the main application without thinking on the platform.

we can experiment with patches and fixes at our own pace

I'm sure it would be possible to have separate forks and experiments even if GitHub Desktop would have _official_ Linux support. :wink:

I can ship new builds out-of-band, without needing to go through reviews and merging into the main repository

But maybe some Linux users would like to have the same stable builds that went through reviews and were build from the main repository.

When a new release is made, I'll pull those changes into my fork, apply the current Linux-specific tweaks I'm currently testing on top of that, and publish to my fork (by pushing a tag to Travis).

Which is awesome, and I appreciate your work. But having it "just" available as an extra fork and having your builds not even mentioned in the official README doesn't make it obvious for many folks that their platform (except Arch) is (kind of) supported as well. The visibility of your work is basically just obvious for people who are following this issue 1525 here.

And permanently having to apply those upstream patches doesn't come for free. You have to do this over and over again. Of course it is strongly dependent on the development speed but it is obviously still an extra effort every time.

There are Linux-specific issues that I've been working through which are independent to the core application, and are ideal to do from a fork

I hope that this was not a misunderstanding here. I'm _not_ against forks per se. I love them in general. But I just would love to have Linux support on the main application. Having the Linux compatible application _just_ available in a fork has various disadvantages.

And just to emphasize that again: Thank you _so_ much for your effort. The application itself and your work to support Linux are so awesome. I can't thank you enough for both. :wink:

[msftrncs]

An FYI, I just built 1.5 beta 5 (via a branch on my fork) last night on Ubuntu 18.04, just to test my PR on a Windows issue, while I was surprised to find no direct Linux distro's, I was able to build and run it under Node (v11). It wasn't perfect, I was getting some kind of connection debug error, but good enough that I want able to test my PR against something other than windows, as I wanted to confirm myself that I didn't upset other OS's while fixing a Windows specific issue.

[MikeOcasio]

Glad to see that this continues to be worked on still, I am new to the whole perspective of Linux so I wish I could be much more help :( but for what its worth I have a lot of admiration for you guys! Hope to get to that level someday.

[shiftkey]

@alexanderadam some extra context:

Well, they are focussing on Mac installations as well, right? So it seems that it isn't a platform independent build at the moment that indeed would allow to focus on the main application without thinking on the platform.

Our team has a strong background in Windows and macOS development, so those installers have been stable and fine for a while. We also have the ability to adapt the application to the platform it's running on, using the __LINUX__ global symbol in code. But the Linux ecosystem is the unknown for us, and my fork is a way to experiment and get _something_ working with those who have the ability to provide feedback.

But maybe some Linux users would like to have the same stable builds that went through reviews and were build from the main repository.

I want to get to that point too, but I also don't want to provide people with broken installers and give them a bad initial experience with using GitHub Desktop on Linux. Getting the app working was the first step (we now test all incoming PRs on Travis), and the current step is getting our installers up to the same standard of our Windows and macOS installers. Once we're at the point where the installers are polished, predictable, and behaving like the other supported platforms, we can start talking about what "official support" means to the team and the community (it's not really elaborated on in in this thread).

The maintainers are already dealing with a very active community (both in terms of support and contributions), and I want to avoid overloading them further currently.

The visibility of your work is basically just obvious for people who are following this issue 1525 here.

I'm okay with the amount of eyeballs on it right now that it has.

And permanently having to apply those upstream patches doesn't come for free. You have to do this over and over again.

Once a patch is upstreamed and merged I don't need to maintain it myself, and over time the number of patches I need to manage should trend towards zero.

[alexanderadam]

@shiftkey thank you (again) for explaining your reasons (and your work in general) :+1:

[cacarr-pdxweb]

@shiftkey

This is directed at the GitHub powers that be, not you specifically -- I'm sure everyone following this appreciates that you've taken it upon yourself to make _something_ available:

"Our team has a strong background in Windows and macOS development, so those installers have been stable and fine for a while. [etc] ..."

Can't you borrow some devs from the parent company? Microsoft has a strong background in Windows (and MacOS) development, and yet their VS Code for Linux is not some unofficial fork.

I mean, we are talking about an _Electron_ app -- cross-platform is much of the whole point of it.

That an entity called "GitHub" can't manage an official Linux app is just darn surprising. It's annoying when some small startup company with an Electron app neglects Linux; it's a real head-scratcher (to put it mildly) when an operation recently acquired for 7.5 billion USD does the same.

One option would be to hire some people with Linux development backgrounds, I would think.

[OunmanNgampeerapong]

Ok

[ipkpjersi]

Will the official Linux builds still have AppImage and snaps for every release? I like being able to choose from debs, rpms, AppImages and snaps currently from the unofficial fork - having that variety is great and helps me out a lot. I'd love to see that continue in the official Linux builds.

[OunmanNgampeerapong]

OKbuild

[salmanulfarzy]

@OunmanNgampeerapong Please don't spam threads :neutral_face:

[shiftkey]

@ipkpjersi I'm using electron-builder to generate these installers ([config file]), which supports many formats. As long as they keep maintaining AppImage support, we're good.

[ghuntley]

When https://github.com/NixOS/nixpkgs/pull/53637 merges GitHub Desktop for Linux will be available for https://nixos.org. :heart_eyes:

[Nosferican]

I am planning to switch from MacOS to Linux for my next computer so would definitely love to have the app available.

[mfonolleda]

I love this desktop app but frankly I am quite shocked it was not available for Linux from day one.

[lyndalopez544]

@hamaminatu You owe it all to Linux.

[danger89]

Is this because of Microsoft who bought Github??

EDIT:
Thank god:
https://github.com/shiftkey/desktop/releases/tag/release-1.2.6

[onigoetz]

@aurora-of-earth @danger89 Please let's not make this a blame game. I also think it's sad to not be able to use GH Desktop on Linux, but why blame Microsoft for this ? This decision was made years before the company was acquired.

Support for Linux will certainly come, we'll just have to wait for this a bit. You can also try other git clients in the meantime, there are some that work well on Linux ...

[ipkpjersi]

How come you guys don't seem to realize that GitHub Desktop has had working Linux builds since 2017? They aren't official yet, but they work pretty well.

[danger89]

How come you guys don't seem to realize that GitHub Desktop has had working Linux builds since 2017? They aren't official yet, but they work pretty well.

You are right:
https://github.com/shiftkey/desktop/releases

[ptomato]

Please read the earlier comments in the thread, many questions have already been answered:

• https://github.com/desktop/desktop/issues/1525#issuecomment-431827651
• https://github.com/desktop/desktop/issues/1525#issuecomment-441020409

Also, please don't post "+1" or "When is it happening" comments. It creates noise for everyone else and makes the real discussion harder to follow. There are hundreds, if not thousands, of people subscribed to this issue because we want to know when _relevant_ progress towards a Linux version happens, but we all get pinged whenever someone comments "Why haven't you done this yet" and it's really annoying.

You can subscribe to the issue to receive notifications, or add a +1 reaction at the top of the page to show that you want this.

Maintainers, would you consider locking this issue so that only contributors can post?

[shiftkey]

Maintainers, would you consider locking this issue so that only contributors can post?

@ptomato while I appreciate the concerns about noise, locking a conversation also prevents people from adding reactions to the issue as well as comments. I don't want to do that unless absolutely necessary.

[cacarr-pdxweb]

Is this because of Microsoft who bought Github??

@danger89

Quite the contrary, I think -- had GitHub been a Microsoft property from day one, under Nadella's watch, I have very little doubt that we would have an official Desktop app for Linux. One has only to look to Visual Studio Code. I'm actually a little surprised Redmond hasn't fixed this.

[cossio]

So.... when is this coming ??

[danger89]

@cossio Check-out https://github.com/shiftkey/desktop/releases in the meanwhile.

[yeluolei]

what's the status for this after twooooooo years?

[ipkpjersi]

There's usable snap builds on the snapcraft store.

[MartinX3]

I made a great snap experience with deprecated package builds.

[probonopd]

https://github.com/shiftkey/desktop/releases has AppImages.

[MartinX3]

Yes, and that's wonderful. :)
Bu I wonder when this repo will release Linux Binaries, too, because this is the official repo.

[probonopd]

Yes, I wonder the exact same thing. In fact, I have never seen such a clear vote in any GitHub project:

[ghuntley]

They may never release official binaries. Be happy that an employee is maintaining AppImages on the side.

[melvinotieno]

So still no word about this?

[roccqqck]

https://snapcraft.io/github-desktop

sudo snap install github-desktop --classic --beta

sudo snap install github-desktop --classic --edge

[wboswall]

I was wondering if there is any update on this issue.

[shiftkey]

There's usable snap builds on the snapcraft store.

@ipkpjersi apologies for the delay in replying, but I haven't had bandwidth to look into this (looks like a required upgrade to the Snapcraft docker container changed some things). Please ensure we have an up-to-date bug report in https://github.com/shiftkey/desktop/issues with the details of what you're seeing.

[JAYSONHOOGY]

Was wanting to get Github Desktop running on my Chromebook and have tried the releases at https://github.com/shiftkey/desktop/releases. Unfortunately, the .deb file can be installed as it doesn't support arm64. .AppImage doesn't work either.

Hopefully, GitHub releases officially supported versions at some point.

[Zyles]

When?

[mikew]

I noticed that the linux fork is quite a bit behind (8 releases behind at the point of this writing). To my surprise, this repo builds on Linux just fine, and from my (very limited) testing, seems to act the same as the fork.

[alexanderadam]

I noticed that the linux fork is quite a bit behind (8 releases behind at the point of this writing).

It will probably always be and I complained about it once already.

Maybe @shiftkey could tell what's currently "missing" when he's back from his well deserved holidays?

[rahulmathews]

I am actually surprised that this feature is pending since 2 and half years. How come one of the most popular development environment doesn't get an application even when its clear that this feature is been supported and liked by thousands.

[msftrncs]

@rahulmathews, I have mentioned this before, because the seasoned developers more likely to develop on 'nix are more comfortable with the original development tools originally built on 'nix, Bash and Git. This doesn't jive with the target audience of Desktop, which is generally for the unseasoned developer new to Git, and those have tended to be on Windows and Mac. As more people start out developing on 'nix, and with less (or no) experience with Git, then a tool like Desktop would seem more attractive.

[rahulmathews]

@msftrncs Is there any alternative for a remote git repo to be viewed in a app like environment(IDE) without actually downloading(cloning) in my local machine?

[Zyles]

I am actually surprised that this feature is pending since 2 and half years. How come one of the most popular development environment doesn't get an application even when its clear that this feature is been supported and liked by thousands.

Probably because Github got bought up by Microsoft and they forced all their slaves to go over to Windows 10 with pre-installed Candy Crush and Disney games.

[mikehfaber]

@msftrncs You're assuming straight off that people who use Linux prefer a command line interface to a UI. I want to be able to work with my branches and commits visually because it's quicker and easier. That doesn't make me some sort of dunce when it comes to 'nix.

[KaKi87]

GitHub been a Microsoft property from day one, under Nadella's watch, I have very little doubt that we would have an official Desktop app for Linux.

+1

Probably because Github got bought up by Microsoft and they forced all their slaves to go over to Windows 10 with pre-installed Candy Crush and Disney games.

+1

You're assuming straight off that people who use Linux prefer a command line interface to a UI. I want to be able to work with my branches and commits visually because it's quicker and easier. That doesn't make me some sort of dunce when it comes to 'nix.

+1

Besides, I'd like to point out that using Linux = say goodbye to UI & UX should not be a fact anymore.
Fortunately, some developers begins to understand that, e.g. Deepin OS, Elementary OS

[tierninho]

Hey folks, let's keep this focused on the issue at hand please. We're well aware that Linux is an important part of the toolbox for a lot of users and I understand that it's particularly meaningful for many of you who have responded in this thread. We've all had times when we wish the tools we use would just have that one feature that means the most to us.

If we can't maintain a respectful tone and stay focused on the issue we're going to have to lock this thread which isn't something we like to do as it eliminates the possibility for people to explain their use cases and offer insight that helps us prioritize features and provides context for how we can best solve the problem if/when we choose to pick up the issue.

If you'd like to add your +1 for this feature please do so by adding an emoji 👍 reaction at the top of this page.

I'm going to minimize recent comments that are either unrelated to this issue and/or aren't written in a respectful tone and I hope we can leave it at that.

[mikew]

Is there an official stance on Linux support? Planned? Don't submit issues (cause they just get linked here and closed)? Don't submit PRs, because "linux isn't supported"?

It would be nice if Github had a way to pin comments to an issue, because trying to wade through the hundreds of comments on this issue alone for an official stance is difficult.

Personally I can get what I need from the current state of this repo on Linux, as I don't really use the "launch terminal" / "open in $editor" features. But the information may help anyone who does notice an issue on Linux and goes to report it / make a PR.

[billygriffin]

We have no immediate plans to support an official Linux version, but we continue to evaluate it alongside our other priorities and we know it's important to many people out there. I also know "maybe someday" is a disappointing response and I apologize for that. We're enormously grateful that @shiftkey has built a fork (https://github.com/shiftkey/desktop) and that many people are using that successfully, but @shiftkey is only one person and I hope people will understand that he's not always able to keep it entirely up to date with the official version.

I assure you that if/when we're able to commit to supporting a Linux version, we'll update this issue accordingly, and I appreciate your ask for a more "official" answer.

I'd also ask that others please refrain from responding to this issue with "when though?", "I want this too", or similar responses. Thanks!

[CircleOnCircles]

What I like most when using the desktop app is its ability to do repo cloning right from my browser. The github website itself filter user-agent to detect OS.

To enable this feature in linux alongwith shiftkey/desktop, we would also need a chrome extension.

[jace]

Looks like @shiftkey's Linux build has fallen out of maintenance. It's still at 2.1 from July 2019 while the official release is at 2.3 beta from January 2020.

As a ChromeOS user, I can't use Snap releases. I'm dependent on Debian/Ubuntu binary releases.

[jace]

There is so little difference between @shiftkey's fork and mainline that I'm surprised a fork is even necessary. https://github.com/desktop/desktop/compare/development...shiftkey:linux

[hron84]

@billygriffin This is okay. Just please don't close this issue.

[OMGdaDPS]

@billygriffin Hey, I know this is off topic a bit, but just wanted to thank you for your work on Base Directory ( I guess it is not just work, is it? lol). I am also interested in the state of things here on this "issue", but thought I would give you a shout out in the meantime.

[rotimi-best]

if there will be no linux version any time soon, a PWA would be nice. Thank you.

[svaza]

This thread was started in 2017, its 2020 now and still no official support for linux. sad to know :(

[Sm1le291]

Hi! How does it go with Ubuntu? Something new?

[alexanderadam]

if there will be no linux version any time soon, a PWA would be nice. Thank you.

Hi! How does it go with Ubuntu? Something new?

Please folks, you can still access the Linux releases here.

edit: @SepSol, the fork is from shiftkey who is working officially on GitHub Desktop anyway (simply check the members page of the project)

[ocdtrekkie]

It’s a significant stressor for me that I have to go to my Windows machine to use the desktop app.

[sepsol]

if there will be no linux version any time soon, a PWA would be nice. Thank you.

Hi! How does it go with Ubuntu? Something new?

Please folks, you can still access the Linux releases here.

Is this official?

[MLDMoritz]

This ticket is nearly open for 3 years and has over 2300 :+1:

How is this still open?

[KristijanZic]

Any news about the official Linux support?

[peter9370]

Please folks, you can still access the Linux releases here.

If the prepackaged versions won't work with a particular linux distro (e.g. if it doesn't use gnome 3 and/or systemd), what's the procedure for attempting to get it working from the source? (I did hunt through the available docs - apologies if I missed a crucial one.)

[shiftkey]

what's the procedure for attempting to get it working from the source?

@peter9370 check out the instructions for setting up your machine for local development

[peter9370]

@shiftkey many thanks for that - will do

[iosifnicolae2]

If you're looking to install Github Desktop on linux you can check out this tutorial.

[cossio]

Show some love for Linux by having an officially supported native version of this app, please.

[peter9370]

The fact that there isn't a dedicated linux version of this is crazy. git was developed by Linus Torvalds to assist in supporting the linux kernel - so without linux, github wouldn't exist.

[cacarr-pdxweb]

Show some love for Linux by having an officially supported native version of this app, please.

GitHub Desktop is an Electron app. There is no "native" version for _any_ platform.

The point is that there ought to be a version for Linux _because_ it's an Electron app, and being cross-platform is at least half of the entire point of Electron.

There not being an official version for Linux would be much more understandable if the Windows and Mac versions were fully native apps. But a cross-platform technology was used, without making the app cross-platform.

[NickWhiu]

Is anyone able to merge the fork at https://github.com/shiftkey/desktop with the linux fork? What is involved for this issue to be closed?

[shiftkey]

What is involved for this issue to be closed?

@NickWhiu please read the issue description for the latest status of this issue.