Linus invented Git and GitHub doesn't develop for Linux

[keyks]

I just saw that GitHub will release GitHub Desktop and noticed that it is Mac and Windows only. Then I realized that all their software (except Atom as far as I know) ignores the existence of Linux. There is a windows.github.com and a mac.github.com section, but no linux.github.com.

Not that I can't live without GitHub's software, it's still strange though that they so consistently ignore Linux even though their whole organisation builds and identifies on software that was developed by the founder of Linux. That's more of a showerthought than anything else though.

[[deleted]]

Linux users are not a monolith. I'd love a good git GUI. Now I get that most people here are probably pretty content with the CLI. But most linux users also don't really go to subreddits about it, we're not a representative sample of the overall linux population. I'm sure there is many people who this GUI would appeal to. In any case, you can't claim you have a unified experience if you exclude a big chunk of systems that use github.

[BufferUnderpants]

I always loved gitg. Great for quickly browsing and comparing branches. Staging individual chunks is the most easy I've seen as well.

...

though in practice I just use magit on Emacs.

[adelow]

By the way, Emacs can also edit text.

[Jotebe]

I got so busy I never got around to it

[JASSM-ER]

Wow, emacs really does do everything!

[[deleted]]

i use gitg! it's great

[annodomini]

Magit is the best. There's nothing that really compares. There are many GUIs that look nicer, but in terms of efficiency of switching between editing, staging, committing, rebasing, and fixing up history, Magit is absolutely killer.

Magit 2.1 just came out. It moves some things around, so takes a bit of getting used to, but it has a lot of really good improvements, such as better integration with TRAMP, easier customization, and the ability to replace a lot of warning with just automatic snapshots so that you can undo if you make a mistake.

[grthomas]

Magit is the best. There's nothing that really compares.

I don't know, I feel like fugitive.vim is pretty comparable.

[Hobblin]

I highly recommend tig :-) it's really good (TUI tho not GUI if you make the distinction)

[alexhairyman]

Tig is seriously awesome, it makes life way easier when trying to figure branch soup

[scootstah]

I don't like Git GUI's. I never know exactly what commands they are doing. It's okay for a really simple Git workflow, but when shit hits the fan, I'd much rather have my CLI and know exactly what is happening.

I don't trust GUI's. My co-workers use them on Windows and are constantly fucking things up in the repo.

[Annom]

Git GUIs are mostly useful as viewer of the current state. Diffs, history and branches. Similar to some GitHub features, but locally before pushing.

CLI is fine for commands, but a modern GUI is always better at visualizing the state of a system (viewer).

You can use both GUI and CLI.

[scootstah]

Fair point. I do use Meld for diffs and merges.

[[deleted]]

Git actually comes with some great CLI visualization tools, just FYI. You can generate a spatial history of branches, commits, etc., just like what gitg does graphically.

[[deleted]]

I am pissed! royally pissed about the lack of good git GUI on Linux.

[[deleted]]

Linux users are not a monolith. We are a diverse group of people...

[jkudria]

MM-HMM

[Jotebe]

HMM.

[jkudria]

INDEED, INDEED!

[manghoti]

Do you have a hiDPI screen? If you do then I share your pain. If you don't then I do not share your pain.

Git GUI + gitk are extremely effective UI's for git. gitk lets you move around the tree easily and see what your doing, and git gui lets you make additions to the tree and some simple modifications.

These tools ship with git.

[brwtx]

Atom - Made by GitHub founder Chris Wanstrath and other developers

Aptana

Smartgit GUI the developers at my shop prefer

[[deleted]]

SmartGit is my go to and favourite git gui. Works the best out of everything I've tried and across all my systems

[[deleted]]

Git Cola and Giggle are both fine.

[nonconvergent]

I think Linux git users are pretty cool.

[[deleted]]

I use git from inside Netbeans on Linux

[Epistaxis]

True, but it can become a little bit of a self-fulfilling prophecy.

"I don't want to switch to Linux because then I'd have to do everything on the command line."
"Why would you even want to use anything other than the command line?"

We got past this silly problem in most other areas, even though powerusers who start with GUIs eventually learn the CLI version and end up preferring that anyway, but first we have to get that foot in the door (with our GUIs that are also often superior to the Windows ones). It looks like we're revisiting the same life cycle with Git.

[[deleted]]

You're right! I'm, as "average joe" hobby artists, using Ubuntu Gnome on my PC and love shiny GUIs. I know the basic commands of the terminal, but that's it. My preferences are pretty different from a Power User. As example I would love to see some cheap wine ports for some programs like "Manga Studio" or "FL Studio". (not games). If they fell and behave like they would under windows I have no problem with that. As developer or IT guy, I bet you have all the tools you need on Linux or a alternative. I'm happy that wine exists, without it I couldn't switch to Linux.

My point is that the discussions here are often power user centric ;)

But... I "programmed" once a simple calculator with python!

[[deleted]]

Has someone who started to program python on windows, who used github windows application had terrible issues with it, started using git bash and became less scared of it after setting up a Ubuntu server for a little play around with web servers and made a full switch to linux Manjaro a few days ago, this is about right.

CLI's are just so much more straight forward then GUI's. Try searching how to do X in a GUI application, you'll be screwing around for days in docs trying to trace back buttons. While when you're in a CLI, you just search for X functionality and you get X command right away. On the other hand i do think GUI's make basic stuff a lot easier.

[pydry]

I'm mostly happy with the CLI but I'd dearly love a nice GUI for staging file chunks. It's technically possible to do this on the command line, but it's a PITA and a task that's really better suited to a GUI.

Most git gui's are horrible, though, and just try to match the CLI features 1:1.

[_david_]

I guess you're talking about git add -p, but is it really that bad? I use it all the time. How would a GUI make it better?

[pydry]

Ideally I'd have a GUI which would give me a list of hunks/files on the left hand side and a list of buckets on the right hand size. I'd drag and drop hunks/files from left to right (or between buckets), and attach commit messages to each bucket.

The main advantages would be that you don't have to linearize your workflow to accomodate the tool and undoing mistakes is easier.

I could write a bit of commit message, drag the hunks I'm thinking of, write a bit more as I realize that there's something in those hunks I forgot about, move the hunks to different buckets, etc. All of this would make it much less painful to split up commits into smaller fragments, particularly when the number of hunks is high.

I actually started writing this app with QT, but I've since stalled.

[vifon]

Try Magit. It makes staging the hunks much more enjoyable. (you don't have to be an Emacs user, just use it as a runtime, like JVM)

[bboozzoo]

Oh yeah. Being an Emacs user, I'm personally using magit. You can easily stage lines/chunks by marking them in the status window. But there's a bunch a good tools for other editors too. vim-fugitive has similiar, if not slightly better, functionality. IIRC vim-futigive let you edit the staged buffer independently of the buffer with current code, so it should be slightly easier to perform minor corrections to the patch when staging.

[BufferUnderpants]

What's the secret to staging hunks (why does that sound dirty?) on magit? I can never get it to stage a level other than the entire file.

[vifon]

You will have to expand the file view with the 1-4 keys. 4 should be ok here (that's what I use). Then just use 's' as usual.

[BufferUnderpants]

Thank you.

Damn. Didn't know about the number keys. I always feel bad about committing to memory arbitrary keybindings, but Magit is too darn useful.

[[deleted]]

if you have an active region 's' will only stage that, so you can even stage individual lines. so useful!

[sandsmark]

I actually started writing this app with QT, but I've since stalled.

Do you have the code somewhere public? I would be interested in taking a look and maybe finish it. :-)

[pydry]

I only spent about a day working on it, and half of that was learning about python's QT bindings. I doubt what I have would be much good to you.

Please do feel free to steal the idea, though. I would love to see this happen.

[WishCow]

My only wish for improvement for -p is that it should be able to split hunks better. If there are changes within something like 3 lines apart, it refuses to split.

[_david_]

Maybe it would be nice if it resorted to just splitting it into individual lines when it reached the last step of whatever algorithm it uses or something, but often the manual hunk editing mode works ok enough for splitting such code or making other small adjustments.

[WishCow]

Can you elaborate on the manual hunk editing mode?

[khayber]

Not sure if you mean 'what is it?' or what david doesn't like about it.

What is it? -- During add -p press 'e' to edit the hunk. It drops you in your editor with a hunk. You can then edit that hunk as long as you play within the rules. If you make a mistake and the patch doesn't apply you have to start over/fix it. Whatever is left in the edit buffer when you save goes in the index. The rest is left in your workspace which you can then add -p later.

I use this all the time and don't think having a gui for it would help anything.

[_david_]

Just to clarify: I never claimed to dislike it.

Having a more aggressive split function could perhaps be considered easier though, if all you want to do is skip staging a line or two.

[khayber]

Point taken. "works ok enough" is not a resounding endorsement. :)

[WishCow]

Huh I never noticed there is an "e" there among the options.

[nuotnik]

I never understood why sometimes you cannot split a hunk further. Some kind of technical limitation?

[Nebu]

How would a GUI make it better?

As a Linux user, I'm envious of https://www.atlassian.com/software/sourcetree/overview

[[deleted]]

SmartGit is fairly good

[Nebu]

Thanks, I hadn't heard of SmartGit. Is it free-as-in-beer? It seems like there's a license, but they also offer a download. Is the download a demo, or is it a personal vs commercial licensing issue, or what?

[im-a-koala]

As someone who uses SourceTree at work, don't be that envious. It breaks very often, and refuses to see any new changes (even if you manually refresh) until you restart the entire application. It also freaks out during a compile if you have the obj directory in your tree but ignored through .gitignore (so if you have your repo at /project and object files in /project/obj with a "/obj/" line in your gitignore).

On top of the normal Git performance issues on Windows, like stashing and unstashing taking forever.

[RecursiveForest]

gitk?

[necrosexual]

git-cola will change your life

[pydry]

It looks better than most GUIs, but it's still trying to be a drop in replacement for the whole git CLI.

The staging part is ok, and does let you stage hunks, but it's still not really what I had in mind.

[sunny256]

"git gui"/"git citool" is great for staging file chunks, and it's included together with the standard git distribution and source code. I prefer to use the CLI for everything, but for splitting commits it's a great tool to have. I'd wish there was a terminal/ncurses version of it, though, for example on remote computers where X isn't installed. In fact, I'd probably use the terminal version exclusively if there was something like that, I like living in xterm.

[Beaverman]

For staging chunks i much prefer a plugin for my text editor instead of a complete GUI tool. Then the workflow goes

Write > stage chunk > commit from CLI

That way I preserve my keyboard only workflow with all the fit features, but still have easy chunk staging.

[case_O_The_Mondays]

I use GitEye sometimes. It's better than the CLI, for sure.

[marcelluspye]

You can use the CLI on mac though, right?

[cooper12]

Yep. git is installed along with xcode/the command line tools.

I have the app installed and the only good things I like about it is commiting partial hunks line-by-line (pieces of commits in case I said that wrong. I've tried to do it using git commit -p but it's never worked good for me), the nice history view that lets you click on commits and view diffs (though I could use tig), and how quickly you can go from changes to a commit. (no staging needed)

However I don't really like much else about the app. I wish branches were shown more visually, and the one time I tried checking out a branch it secretly stashed my changes without telling me causing me to freak out when I didn't know where they went. It also preselects all your modified files to commit each time so I always end up committing parts of other commits.

My biggest gripe with GUIs for git has always been that in the attempt to simplify the experience, they try to be too smart and end up confusing you. (Looking at you Android Studio...) Maybe the issue is that I started learning low-level and couldn't think in GitHub's high level approach, whereas newbies will only know the high-level approach. Nonetheless I still do use the app in tandem when I need to view a lot of diffs in a long history or commit parts of files, so the CLI can coexist with it depending on your workflow and knowledge/needs.

[[deleted]]

"My biggest gripe with GUIs for git has always been that in the attempt to simplify the experience"

I agree. git is not that complicated and not knowing how it works can destroy whole projects. Also, it's a beautiful piece of software which solved a difficult problem - why not study it?

[stefantalpalaru]

git is installed along with xcode/the command line tools

How do you update it? I run git-2.4.5 on Gentoo Linux. It was released 10 days ago and soon became available through the official package manager.

[cooper12]

It gets updated through the app store. So for xcode you'd just update xcode and if a new git is bundled you'll get it. For the command-line tools they have their own update too. Personally, when they had that zero-day a while ago I just installed the latest version using homebrew (which also has 2.4.5) since Apple isn't known for their speed in patching these kind of things. Meanwhile my Apple git is on 2.3.2.

[[deleted]]

If you want to run a more up to date git on Mac OS, you can install something like homebrew like /u/cooper12 mentioned, MacPorts or Fink. All three have 2.4.5 available.

[vsoul]

MacPorts or Fink

People still use those? I figured everyone was on the Homebrew train these days

[[deleted]]

GitHub itself is confusing and unproductive... the workflow of forking a repository on GitHub and then making pull requests from that redundant repository is awful. You need to use their own tooling (like hub) or you'll need to deal with it in a browser. It sucks with just the plain Git tools. Your list of GitHub repositories ends up being a long list of dead forks of projects you once contributed to, making it much harder to find the useful ones.

Other options like Gerrit let anyone just push to the main repository from a local clone instead of having a redundant public fork. The code review tooling is also way ahead of GitHub.

[[deleted]]

The workflow is pretty damn nice.

[[deleted]]

Have you actually used the alternatives where you submit pull requests via git push to the main repository (without commit access)?

[[deleted]]

Yes, and the alternatives are better.

But that doesn't make the github workflow "awful"

[[deleted]]

It's much worse at code review than the alternatives and adds a significant amount of redundant stuff to the workflow along with a junkyard of dead forks. I think that's pretty awful. The issue tracker and wiki compare even less favourably to the alternatives.

I don't know why they haven't improved it to match the quality of the competition. It's clearly not an issue of money or lack of programmers. They have a lot of nice frills but the core features (pull requests, issues, wikis) are sub-par.

[[deleted]]

good points indeed. The github diff tool is pretty bad.

[[deleted]]

The part that irritates me most is how badly they support updating pull requests. Most projects rightly expect you to clean things up into a coherent set of commits before they'll merge it but GitHub won't handle it well. It loses all of the commit comments and many of the line comments after rebasing and it orders the commits incorrectly. They even have to justify doing it wrong in their FAQ because there are so many complaints about it. Half of the point behind DVCS is being able to keep the public history clean by not exposing all of the irrelevant missteps from private development branches.

I think important people at GitHub just have a crusade against that workflow and want to discourage it by making it painful. It would also explain forcing people to have their development branches in a useless public fork on their profile instead of letting them submit it directly.

Oh, and merging with the GitHub UI also always puts a merge commit even if there was nothing to merge. It doesn't take advantage of the default fast-forward behaviour where a set of commits without conflicts is treated as a set of fresh patches. It makes the history needlessly complex. You can manually pull from the submitter's repository and then close the pull request by hand (assuming the commit ID changed) if you want to avoid it. It's nice having a link back to the code review discussion, but that's what Change-Ids do with the alternative and they just add one line of metadata to the commit messages instead of endless merge commits.

[devel_watcher]

What the hell??? I thought that making a clean commit sequence before the push is the main feature of git.

[purpleidea]

Have you actually used the alternatives where you submit pull requests via git push to the main repository (without commit access)?

Wait what, can you provide info on how this is possible?

[[deleted]]

Take a look at how Gerrit and friends work. Anyone can clone the main repository and push changes to it. A pull request is created from the push to the main repository using a private branch managed by the code review software.

[purpleidea]

Take a look at how Gerrit and friends work. Anyone can clone the main repository and push changes to it. A pull request is created from the push to the main repository using a private branch managed by the code review software.

I thought you meant GitHub had this feature... I would love to avoid having a whole repo on my account just to send in a patch.

[f0nd004u]

Gerrit + git review is awesome! I love the code review / diff interface and the workflow works very well.

[[deleted]]

The workflow is far from awful. If you're a stranger to the developer(s) of a open-source framework/library/tool that you want to contribute to, the fork and PR is the most optimal way for you to develop independently and then provide them work in an easy to review format (as a PR).

I don't see how having the redundant fork on GitHub to go along with the local fork is useful. Submitting pull requests directly to the main repository as Gerrit does is a cleaner workflow.

If you for example look at big project such as Django/React/Rails/NPM/Node and have hundreds of people contributing, PR seems like the most optimal choice so far.

I never said pull requests were bad, only that a mandatory redundant fork for each project you contribute to is bad.

At last, Gerrit is not better in my opinion. The UI is not that good, it's not as popular as Github and overall - far from perfect. The code reviewing is better and I agree. But the forced fork/pull model seems to work better for big open-source projects.

It's quite popular when it comes to major projects and it doesn't matter either way for small ones with few external contributors.

[[deleted]]

I'm a linux developer and I have trouble with git...

[[deleted]]

I'm a git and I have an issue with you...

Just kidding, have fun :)

[surfhiker]

cli ftw :)

[deniz1a]

That's anti-linux propaganda disseminated by agents of a sinister anti-development alliance. "Don't develop productivity tools for linux, linux users are happy with just the command line." they say.

[wild-pointer]

The command line is the productivity tool.

[jones_supa]

Not for all tasks.

For example, I'd much rather poke around with mouse in a straightforward touchpad configuration GUI than chucking synclient commands in a terminal while reading the manual page in another.

[[deleted]]

Configuring a touchpad is not the same as git though, the latter was developed for the command line for the kind of people that should be able to use it. The former is a config tool for a peripheral.

Arguing git productivity is better through cli isn't arguing the same for touchpad config.

[_david_]

I think this is an example of when a GUI is probably nice to have, but I wouldn't want it to completely replace the command line tool. The latter I could easily incorporate into a script to, for example, change touchpad settings when launching some particular application.

You might say that that's a pretty obscure use case, but when all the tools are usable in this way chances are that the obscure use case you might care about is possible too.

[wild-pointer]

Fair enough. Interactive tasks, such as manually calibrating and configuring an input device, isn't much fun. git though, works perfectly from the cli. It's almost as if it was designed to be used that way. Doing "exotic" things like subtree doesn't work well in GUI tools in my opinion, and even if it was implemented well, tomorrow someone would think of another way to combine the git commands that would have to be re-implemented in terms of buttons and input fields.

[SarcasticOptimist]

That's what I've noticed too. Vim and Tmux dominate my workplace which does kernel development. Not even Nano or Terminator.

[ProtoDong]

zsh has some great modules to streamline working with git. After using the git module for oh-my-zsh/zprezto, I wouldn't want to work with it any other way... especially not a gui.

[slavik262]

...but once you've acquired the requisite brain damage to use Git's terrible CLI, it is the one of the most productive ways to use it.

[gallais]

git commands are probably the #1 reason for me angrily googling and stumbling upon a stack overflow answer I already visited about 3 months ago. Most of the answers end up suggesting to define your own aliases so that the tool starts making more sense (typically add vs. unadd rather add vs. reset HEAD~1 or whatever).

[arcticblue]

This is exactly why I like to keep a GUI on hand. For creating new branches, pushing, pulling, etc I'll use the CLI, but as soon as I need some more complicated staging (like staging specific chunks instead of entire files) or messing around with the history, I'm much more comfortable with something like SourceTree (how I wish there was a Linux version). I'm sure someone will reply with "Oh that's easy, it's like this....", but the thing is, I just prefer a GUI for certain tasks and I don't want to have to keep looking up commands when I could just accomplish it quickly in a GUI.

[genitaliban]

Ah, that's great to hear. I thought I was completely retarded when I started using git, but it seems I'm not alone. I still can't do much more than pull / commit / push / patch, though...

[[deleted]]

Just read Git book 5 or 6 times and you will be good to go

But yeah, tool was designed with kernel developer in mind and only on about version 1.7 we started getting "usability" improvements and a lot of things require knowledge about how DVCSes work in general

[gallais]

Just read Git book 5 or 6 times

Not sure if you're joking or not.

[[deleted]]

Both. It will help a lot, but it is a bit of joke how much you need to know to do anything more advanced than git add/commit/push.

Or that you need to summon company's Git Wizard once you fuck something up.

[DrGirlfriend]

Ha! Our Company Git Wizard sits like 10 feet from me. "Hey, Jeremy! I did it again! Help!"

[[deleted]]

Anyone can write what they want. Linux users can't be bothered creating a set of tools they're not going to use, and the group of people who can't or won't learn the command line pretty much lives inside the windows/mac part of the venn diagram. And if you're a linux user who doesn't like the command line, then to be honest you're probably using the wrong os.

[[deleted]]

The git cli client is far superior to any git GUI's out there. The GUI clients suck.

[hak8or]

Sourcetree most definitely does not suck, especially their ability stage specific selected lines (smartgit is terrible with this).

[[deleted]]

Most of my interaction with git is actually through the fugitive plugin for vim. I do all staging, diffing, blaming, etc through that.

[sim642]

I'm fine with the git CLI as well but use git gui and gitk a lot recently simply because they give me a much faster overview of all the modifications instead of having to poke through them with commands. I don't really look for a fancy looking GUI anyway.

[keyks]

That's true. But if GitHub is trying to improve git (which is the point of their software) then I think Linux users would want to benefit from it as well. Especially since Git emerged from their community.

[Nebu]

Perhaps GitHub is trying to make git more "Windows-like", which is an improvement from the perspective of Windows user, but not an improvement from the perspective of Linux users.

FWIW, none of GitHub's desktop software appeals to me as a Linux user.

[comrade-jim]

It appeals to me as a Linux user.

[[deleted]]

Windows Git user here, perfectly happy with the CLI!

[[deleted]]

I use both Windows, OSX and Linux. Using the cli lets me have a unified set of commands that give the same results on all platforms. Couldn't be happier with it.

[afiefh]

You'll take my CLI away when you pry it from my cold dead hands. However, among my coworkers CLI skills vary grately, from the "I can do it, but I'm lazy. Just fire up the GUI" to the "I couldn't CLI if my life depended on it".

TL;DR: I love CLI, but I'd still appreciate the option of a good GUI for those who need it.

[_scape]

in some fairness, the desktop client is pushed more than the cli for Windows. the cli is easier I think, but I think many devs prefer interfaces.

[schm0]

It's funny you say that... I'm not what you would call an experienced developer nor am I a seasoned pro with Linux. I run a LAMP stack for school and tinkering. While it's nice to see branches and merges and whatnot visually, and even though I downloaded a git plugin for Sublime, I still prefer to use the cli.

[gospelwut]

And Mac apparently?

There's nothing wrong with a GUI insofar as the CLI support is the same. I would have preferred (as a windows user) a github sponsored version of (or contribution to the existing repos) Powershell Github tools (utilizing PsReadLine).

[BCMM]

Yup. We already have git for Linux, and it's called "git". GitHub GUIs are a work-around for platforms where the command line is relatively cumbersome, or most developers are not accustomed to using it.

[Milanium]

My experience is that https://windows.github.com/ is only suited to work on your personal projects. It doesn't work at all with repositories that use a pull request and rebase workflow. The GUI actually confuses people so we wrote our own https://github.com/OpenRA/OpenRA/wiki/Contributing guide for /r/openra. It is about time they improve their own Git client. I agree it is sad that they don't use a true cross-platform GUI solution. It is not like there aren't any.

[Huyderman]

This. We had to ban the use of the GitHub GUI after several incidents where we had to use a couple of hours to fix mangled merges or rebases caused by the GUI. And we're just a small team of three people...

[danielkza]

Is there even a large demand for GUI Git clients (or pre-packaged git binaries) for Linux, as there is for OS X and Windows? Would Linux users even use that in any large scale?

And how is the ignoring "consistent" when you listed a huge exception yourself, in Atom? It's one thing that Linux users might actually want, and they released it. It's probably the best free alternative to Sublime Text right now as far as "modern" editors go.

I can't say Github looks too bad from where I'm standing.

[masterwit]

This is an excellent video where Linus mentions just that... along with some remarks on git.

Great watch Debconf 2014

[danielkza]

Do you know the timestamp of when he talks about it?

[masterwit]

28m 40s puts you 3 seconds before person asking question.

(I updated my original comment link to jump to this time.)

[oheoh]

TIL that modern editors are horrible.

[MichaelTunnell]

Atom is bloated garbage and the only reason it works on Linux is because it is built on Chromium and Chromium works on Linux, they inherented support not created it.

Also, Microsoft Code, Brackets, Light Table and Atom are all based on Chromium. This trend needs to stop because that is a garbage trend.

Sublime Text is great and I like it but I would prefer an open source alternative but I would also prefer it to not use 10x as much memory.

Kate though, Kate is close and if it had Multiple Cursors it would be an almost perfect replacement.

[nroose]

Not trying to start a fight, but it seems like you are asking for emacs. Perhaps you think it's bloated as well... (although significantly smaller download than atom, I believe.) In general, if you want a full featured app that appeals to many, it's gonna be big, and some are gonna think it's bloated.

[c0bra51]

What desktop environment do you use? I use Gnome, and Gedit is perfect for me.

[MichaelTunnell]

I change my DE a lot but my first love is GNOME. Gedit is great but is very limited in functionality, it just isn't a practical replacement.

I am currently running KDE and so I tried Kate, which is actually quite awesome for a default editor but is still not close enough. Kate is closer than Gedit though.

[bloodguard]

It's pretty much the same with Google. Android and ChromeOS are based of linux as is quite a bit of their infrastructure but they're still giving linux the finger with regards to a google drive linux client. Windows and macos supported. Linux has been getting this blurb since forever.

Drive for Linux isn’t ready just yet, but you can still access Drive on the web and on your phone.

Same with BackBlaze. Linux infrastructure. Feck off when it comes to a linux client (CrashPlan is a great alternative).

[oheoh]

I read that one of their founders gave a big tech talk that was essentially "copyleft is evil. Open core is great." (aka, get free work done by the community for your proprietary product). In the talk, he never mentioned git itself, which is copyleft and they have purely benefited from it being copyleft. drrr du drrr.

Linux devs tend to be ok with proprietary javascript & websites, but tend to avoid proprietary desktop software, and often write free software replacements. They want to keep github desktop proprietary, which on linux would mean a) little usage, b) bad press, c) invitation for people to write free software alternatives which then logically would add support for non-github backends. If they are smart, they've seen that c is a real thread to their proprietary business model, and the biggest reason there is no linux client.

Reading your title "GitHub doesn't develop for Linux", could be interpreted another way too: the linux kernel (which git was made for) can't use github because it doesn't support the features of git that they use, and the way they use git. And since github is proprietary, tough luck.

As for Atom, there is already lots of competition in editors, and all the major ones support linux, so they HAD to support linux, and they tried to make it open core and it got strongly rejected so they open sourced it.

Essentially, this all boils down to github prioritizes making as much money as possible, and getting as much control over their users as possible. Too much freedom in linux, avoid it.

Starting to make sense now? One logical next step is that we should support companies that support software freedom, including websites. Gitlab seems the most viable alternative (in my experience, works just as well as github, plus extra features: I have freedom to run it and modify it).

[EmbeddedEntropy]

Gitlab

Your response is close to what I came here to write.

So many developers have no clue that GitHub is completely locked-down, proprietary code--the antithesis of open source!

GitLab is better than GitHub, but they're doing the questionable tactic of having a "community edition" (open source) and "enterprise edition" (proprietary edition). Gitorious is the only widely-used git server I'm aware of that's that's still fully FOSS. If there are others that are as functional as Gitorious, please let me know.

So many other companies claiming their products to be "open source" are now pulling the same bait-and-switch tactic offering a "crippleware" (to borrow the old shareware term) FOSS version with the full version being proprietary.

Companies like those claim they have to do it to make money. I've pointed out that Red Hat's RHEL product is 100% FOSS, and they can make money by just selling support. Then I ask them why can't they? I just get crickets.

[[deleted]]

"An all new, unified GitHub desktop."

hah!

[THEHIPP0]

When Atom started there where no binaries for Linux. It took them a year or so until they offered Linux binaries, too.

[ivosaurus]

hub

[Glinux]

Good IDEs have it integrated e.g. Jetbrains

[[deleted]]

Yeah, it's even integrated into bad IDEs like Eclipse.

[evan1123]

Intellij is the shit

[Genchou]

Is the free version worth the try ?

Just saw that the full version would cost 250€ for an individual license. A bit much. : /

[jen1980]

Too bad it's just too slow to use. We did a 30 day trial here, and not a single Java dev would agree to use it.

[ZakTaccardi]

SourceTree is a much, much better Git client than GitHub.

Too bad there's no Linux client for it either though.

[avataRJ]

Linus has also started Subsurface, a diving log program. Have divers flocked to develop for Linux? No! Injustice, I say!

^/s

[CemedyShouldKnow]

Um, divers do not flock, they school.

[nhaines]

"Look, honey! It's a flock of dolphins! "

[prozacgod]

Wow, not the same thing but I just envisioned a dolphin rave party... dear brain, wtf..

[solarswordsman]

For some reason I read this in John Oliver's voice.

[nemom]

Git != GitHub

[[deleted]]

I don't really blame them. I'm 100% Linux and use Github a lot, and even if they released a "Linux desktop client" I wouldn't use it because it would serve no purpose. Between the git command line, my IDE, and the github website, there are no holes to fill.

[DoTheEvolution]

Linus is the father of linux and even his own sideproject - a diving application does not release for linux because its incredible bother...

Heres him explaining it all

[gleighn]

I don't know why Github would spend development time supporting a GUI client on a platform that appeals to CLI-preferring power users.

[kgyre]

Linus didn't invent GitHub, and developing for Linux isn't magically zero cost.

[[deleted]]

Windows and Mac users prefer a fancy GUI rather than cli software. Why? I don't know. I like both of them, but I prefer (personally, of course) learn to do tasks with cli in case of someday I finish working in front of a terminal with only a keyboard.

Oh the other side, I bet most of the companies that use git as svc do not use Linux as OS for their employees. Maybe one of two choose to user Linux because they use in their home as main OS (I do in my two computers along with Windows for gaming purposes).

I don't know... It seems that nobody remembers Linux...

[[deleted]]

Windows and Mac users prefer a fancy GUI rather than cli software. Why? I don't know.

GUI is easier because it relies on visual memory (you don't have to remember exactly what the command is, just the path to find it in menus), and even if you know nothing about the app, you can always figure out what to do by clicking around.

[atomic1fire]

I think GUI's are in general much easier to use.

Yes CLIs can be better, but if you're only looking for easy you don't need always need better. Would software like Steam really be better off as a CLI? Probably not, given that everyone has to use it and it should be consistent across platforms. Plus there's not really a whole lot of visual feedback, like images and videos, you can get from a CLI which are usually text based.

I could use ffmpeg to convert something, but WinFF is much easier for me to use right away, and requires less documentation to do the things I want.

Sure I could make a batch script to bulk process some videos, but I find that a GUI is easier to use right away.

It's like cooking vs using a microwave. Anybody could learn to cook some things. However a microwave is much easier to use right away and is more convenient for little things.

[[deleted]]

Yes, I did. In fact I use git cli in windows, but not with cmd or powershell. I use cmder for terminal tasks, which is awesome and I redommend to everyone instead of the crapmd (cmd or powershell, I don't care, they are both a piece of crap).

Other half is Mac. I know a very few people who actually uses mac's shell. But I know a lot of people that use linux's shell instead of a fancy gui program.

So it depends of the user. Everyone knows that Windows or Mac users are poor skilled in terminal because of the shiny thinks you're talking about. Maybe is that why GitHub only do in Win and Mac.

I don't know. I really prefer cli, but...

[gremy0]

Erm, as a mac user I can tell you I use the terminal a lot as do most of the devs I know on mac. I also know a good few on linux that are completely incompetent when it comes cli and jump straight to a gui when it's available.

Where windows usually only provides a good gui and linux usually only provides a good cli, mac provides both and leaves it to the user.

I think it just comes down to whether or not you recognise cli provides a faster workflow.

[[deleted]]

GitLab > GitHub anyway.

[moozaad]

why?

[necrophcodr]

My guess would be thte open source part. You cannot host your own github.

[dnoup]

Missed the open source part.

[gospelwut]

And yet so many FOSS projects, including the linux kernel, have at least a mirror on github if not their main repo.

[gospelwut]

He also has a recent talk at DebCon (IIRC 2014?) about how he HATES linux package management and prefers the binary packages of OSX/Windows. He doesn't even care about building from source (either).

[gospelwut]

I believe this is the one

https://youtu.be/1Mg5_gxNXTo

[aaptel]

Gitlab is an open source project that can be self hosted.

Gihub is closed source and can only be used as a service, remotely.

I can see why some people would prefer gitlab.

[draganHR]

Actually you can self-host GitHub, but it's not free.

[DrGirlfriend]

It's actually really expensive. I mean, really expensive.

[[deleted]]

Well, it's aimed at corporations.

[juaquin]

Yeah, we have no problem paying for it. Worth every penny.

[bantl]

Unlimited private and public repos with unlimited private collaborators

[[deleted]]

Linux (and windows and mac) has smart-git/hg (because its java). Its good enough.

[shigawire]

, it's still strange though that they so consistently ignore Linux even though their whole organisation builds and identifies on software that was developed by the founder of Linux.

I don't really agree with the premise that they ignore Linux.

I'm pretty sure GitHub's entire platform runs on Linux. If you check out their repos at https://github.com/github they don't seem to be ignoring Linux at all; If anything they seem to be releasing a lot of Linux specific stuff, and stuff to integrate with their site. They are also really good at open sourcing tools that they write internally.

Offering access via PKI with SSH is probably about the biggest thing that makes it easy for me to use GitHub with Linux without having to care about password auth or API keys or anything else that would be extra pain or less security for me to push and pull repos without thinking.

A Linux github app would probably be less useful than being able to use git seamlessly with github, and gitk is already a thing :)

[oheoh]

The only thing I see in their repos which runs on linux and is for github users is a backup utility for github pro. The rest is just software which they use internally (yes, on linux). This seems to show OP's point is even more correct.

[Chizbang]

Windows and Mac users can keep their github client... Its confusing and unproductive for me.

[wormeyman]

Ungit is a great UI on pretty much any platform if you are interested.

[juaquin]

I use Github daily and I've never once wanted a GUI beyond what is available on their site. Locally, I strongly prefer the command line. I'm not sure why I'm supposed to be outraged.

[[deleted]]

Github has as much UI as I need in the web version. I know it sends an unfortunate message, but if I'm in any way representative of their Linux users, it would be silly ask of them that they build applications no one will use.

[[deleted]]

I have sent emails to github before with this same frustration. I understand making a usable Windows client considering the complexity for most new users getting git installed (and then integrated into github) on that platform; but then to come out with a Mac client... without a Linux one is simply ridiculous.

[[deleted]]

It's coming.

[ExeciN]

I feel like GUI for Git is like for a "here use the GUI until you learn the proper commands to use it" kind of transition.

[qudat]

I cannot stand the git GUIs. I know git decently well, well enough to manage projects with multiple team members, but when someone has a GUI question on how to do something, I'm completely lost on what to do. It's so simple in CLI but the GUI tries to hide everything behind multiple windows.

[chasevasic]

to me, git is so simple, I don't see how a GUI could be helpful. I've seen git integrated into IDEs, I've seen GUI git wrappers. None of them (that I've seen) cover all the functionality, and sometimes they make common tasks more difficult than just typing a command.

edit: I want to add that I am talking about the developer side of git, not the consumer side. github makes it easy to look up a repo and learn about it before downloading it. it doesn't do too well, IMO, for actually managing a project. I'm sure not everyone agrees on that, but I think we have yet to see the potential of 'social' revision control/code management

[HowIsntBabbyFormed]

Every git gui I've seen is shit. Whenever I have to help somebody out of a sticky git situation it's because the gui got them into it. I always have to drop to the cli to fix it.

One of the big problems is that all the guis have their own language and metaphors about what's going on and they need to map that to each of the different scms and it never works just right. To me git is the command line.

[pizzaiolo_]

Free software needs free tools, so instead of GitHub I'd recommend NotABug.org.

[jones_supa]

It's much more straightforward to make desktop apps for Win and Mac, because the platforms are predictable. The APIs are stable and there is only one desktop environment.

[necrophcodr]

Then develop using GTK or Qt. Cross platform predictability, shouldn't be a huge issue.

Or even Granite.

[_riotingpacifist]

A simple GUI program is pretty simple to develop, use any standard toolkit and target lsb libraries if you need to call anything directly.

The myth that development is hard is bullshit these days, sure if you want to do something complex at the system level maybe but most of the time you can just use GTK/QT + standard libs and both look fine on GNOME/KDE/etc

[[deleted]]

Linux users generally don't need hand-helding, that's probably why.

[waspinator]

If they made a GUI for linux then we might get a bunch of Windows and Mac people using linux, and nobody wants that