Its a shame that a Linux version is not included. A significant volume of developers work on Linux. If doing a multi platform application, why exclude it?
It's likely they felt it's not worth the time since most Linux users are using the CLI for everything else, and likely wouldn't be interested in a GUI. Personally I've never used the Github GUI and have no plans to, running the commands is fast and easy.
I think it's a myth that Linux users aren't interested in GUI tools. According to stack overflow statistics, Ubuntu is the most popular Linux based OS amongst developers, which is an OS that is much more GUI based than say Arch linux.
According to the same stats, Linux and OS X usage is statistically tied at ~21%. If you take into account the fact that only about 2% of computer users run Linux at all it's pretty clear that programmers disproportionately prefer Linux (and to a lesser extent OS X) to other systems.
I personally have already moved away from github, but I still wish they would build some tools that work on Linux.
Let me preface this by saying that I am a full-time Linux user and have been for several years.
I run Debian on my laptop and Arch Linux on my home machine. Both use i3 (no DE), and I do all my work at the command line or in applications that I launch from the command line[0]. I love the Linux terminal. I don't even own a non-Linux machine, not counting the various OS X devices I've used at work when one is required.
> I think it's a myth that Linux users aren't interested in GUI tools.
It's definitely a myth, and a very dangerous and self-fulfilling one. I would strongly appreciate a GUI option for many common command-line tools. I like the command-line, and do most of my work there. But sometimes GUI tools are nice to have. The problem is that most GUI tools on Linux really suck, and most Linux tools don't even have a GUI at all[1]. Contrary to popular belief, it's not due to the inadequacy of GUI toolkits on Linux, but simply due to a lack of time actually spent developing these tools.
This ends up being self-fulfilling, because it raises the barrier to getting started on Linux, which keeps out people who would be otherwise very comfortable on Linux as an OS, but simply dislike being forced to use the command-line exclusively.
[0] Never bothered with dmenu, never really felt the need to set it up.
[1] I'm not counting ncurses-based interfaces as GUIs for these purposes.
> I am a full-time Linux user and have been for several years. I run Debian on my laptop and Arch Linux on my home machine. Both use i3 (no DE), and I do all my work at the command line or in applications that I launch from the command line[0]. I love the Linux terminal. I don't even own a non-Linux machine, not counting the various OS X devices I've used at work when one is required.
Wow, that's exactly my case as well :).
I could've written this, almost word for word (except I run debian on my servers, and archlinux on my laptop/home machines).
I for one feel very uncomfortable using other OSes due to the lack of text UIs. And it seems pretty likely that a vast majority of linux devs feel similarly, considering how few softwares start out with just a GUI instead of the other way around.
Shameless plug: I recently built a new linux GUI git client. The people who use it really like it. Still working on docs to better explain what makes it different. Like GitHub's client, it's more than just a wrapper around the CLI, but unlike GitHub's client it exposes git's full power (tags, cherry-pick, rebase, etc.)
If you'd like to try a new linux gui client, give it a spin!
Your diffing doesn't suck! That alone is really valuable. What really sucks on Windows is merging: there are very few products that deal with merging at a basic competency level (the git merge markers usually wreak havoc).
One criticism: that jgit tab needs a serious UX pass. It's extremely scary looking to someone who has never used it (me).
That being said, I'll be keeping a very close eye on your kickstarter. Very close.
Thanks for the feedback! On the spectrum from "iOS" to "airplane cockpit", I think GitHub is trying to be iPhone, but I think git has enough inherent power (like an aircraft) that you leave a lot of functionality on the table if you constrain yourself to a "no training required" interface. It's certainly something to aspire to, though! If there's anyone out there who thinks they can clean this up, I'm always looking for partners :) Based in SF, open to remote collaboration, contact info in my profile.
The differ / merge resolution story is gonna get a whole lot better real soon.
100% agree! Was hoping to have the full manual done today, but it's not ready yet. Kinda worked out - I'll spend today ducking as the GitHub goliath whooshes over me for HN readership's attention ;-).
The rest of the product's docs are complete and full of screenshots:
so the git client will be too. This client animates changes to the DAG, so I'm experimenting with animated gifs so that the manual can capture the feel of using it.
I don't think it's a myth, but it definitely is self-fulfilling (since it puts off users who would otherwise use Linux, but don't because they don't want to exclusively use the CLI)
Personally I use a mac nowadays but still use and prefer the command line for this kind of thing. I tried using Github for Mac but quickly gave up the first time I had to do something vaguely complicated.
I guess I'm still a linux person at heart - you can tell if you prefer to 'brew install everything and have never actually used the App Store except to install Xcode :)
My discovery of `brew cask`[0] has meant that the App Store is avoided at nearly all cost. I'm a Linux user at heart, too -- one of the only reasons I use OS X is that it feels like "Unix, but with nice powerful GUI apps as well"!
I wouldn't try to speak for everyone who uses Linux of course, it's just been my observation. With my "roots" in computing being in the command line driven 80s, I still feel way better using command line stuff and likely will never change. It doesn't mean I am opposed to GUIs in general, there are certainly things I would never consider doing from a command line, but git isn't one of them.
The problem with this attitude is that it makes it far more difficult for Linux distros to gain more varied users. Specifically those who are new to development, or (not really relevant in this case) not developers at all. Instead of pointing to a CLI for everything, which I personally love and support for what it is, it might be worth encouraging companies to develop more cross-platform software that allows for a choice of operating system without many sacrifices.
I agree 100%. More GUI tools will most certainly attract more people to Linux and something that shouldn't be overlooked. For the record I was just guessing the reasoning GitHub overlooked it, there could be other reasons I'm unaware of.
It's rather embarrassing that github would consider it too difficult or too troublesome to release Linux builds. Very insulting towards a huge chunk of its user base.
Regarding GUI, how do you initiate a pull request on the command line?
It demonstrates a lack of concern/acknowledgement of the diversity of its user base. Especially if they are going to be promoting this on the front page of their website and in my dashboard upon login, which presents me with the broadcast:
"GitHub Desktop is now available
The new GitHub Desktop is now available"
And then I click on it to install it, I feel marginalized and hence a little insulted, when discovering I can't.
In this day, there are a great variety of cross-platform gui toolkits (e.g. https://en.wikipedia.org/wiki/List_of_platform-independent_G...), that could have been used. It is embarrassing for such a large organisation with all sorts of users using all sorts of machines to not release cross-platform tools. It if was just someone's personal project, or if it was a company's specialized toolkit for their specific customer base, the lack of cross-platform tools is excusable.
> I feel marginalized and hence a little insulted, when discovering I can't.
I feel you; I used to be a Linux desktop user and an advocate thereof. But that's the price that you pay for using the distant, distant third most-used OS for a company trying to drive user engagement with their product. You (the collective you) have to be an attractive market if you want commercial entities to consider you worth marketing to, y'know?
Or maybe, just maybe, they are very aware of their user base and that's the reason there is no version for Linux?
Should I get upset that they don't have Lithuanian version of the app, and hence demonstrate a lack of concern/acknowledgement of the diversity of its user base?
That's not a comparable anaolgy. I can't find data on the number of linux users vs the number of lithuanian users, but the number of linux users is orders of magnitude higher.
No. Github is built on git. Git was written by Linus Torvalds. You see where this is going? Oh, we'll build our tech on your side project but ignore the user base of your main project. Nice.
thanks, but the context was how to create a new pull request to github from commandline, which I don't believe git request-pull can do. Another comment mentions https://github.com/github/hub#git-pull-request which seems to be what I am looking for.
Linux has been my primary desktop OS for almost twenty years, and no, I have no problems using good GUI tools when they're available. I'm happy to use a Git GUI to review changed files and selectively choose text hunks from them for a specific changeset, for example. Often I'll just do it from with Vim with Fugitive, but that's a GUI too, by any definition.
right. But it is a nice clean GUI, that handles the 95% percent without any fluff. The git program is very complicated, designed to handle large projects, and it does have a learning curve (especially to keep all the commands straight e.g. git branch -l, git branch -d, git checkout -b, git "reqeust-pull"???). When I was first learning git, I was a little overwhelmed at its variety of commands in the man, and would have preferred this GUI where I'm able to simply click on repos, click to create a branch, and click to create a pull request, to handle 95%+ of use cases. Even hardcore linux users like to use simple GUI tools, sometimes.
But it's not about git itself. Issues, PR comments, the wiki and such things make github what is. Personally, I'd prefer a nice graphical desktop app to handle these, and either have a terminal embedded or run it alongside the gui to handle the git commands.
I use the CLI. Still, that's not the point. Mac users use the CLI too. Some Windows users as well I'm sure. We now live in a Triple-Platform world. Linux is not a sideline project. Its a major Operating System. If OSX gets it (BSD), surely it can be compiled to Linux. Its multi platform anyway so why not go the full distance?!
This seems strange. Did they not use Electron or Atom Shell or whatever it's called to build Github Desktop? If so, then is it not relatively trivial to create a GNU/Linux (or at least non-OSX-centric Unix) tarball of all the Javascript or whatever? If not so, then why not?
Because Electron is heavy and clunky. It makes no sense for a simple wrapper around a tiny (less than 1MB) commandline tool to have memory and CPU requirements on par with those of an instance of Chromium with a javascript-laden page open in a tab.
If it's really just a wrapper around the git command, then I suppose I'm not really interested anyway, then, seeing as the existing Git GUIs for Linux provide that rather well. I was assuming it was like the Mac client where it provides Github-specific functionality (adding "Clone in Desktop" buttons to repo pages, managing pull requests, etc.).
I was assuming it was like the Mac client where it provides Github-specific functionality (adding "Clone in Desktop" buttons to repo pages, managing pull requests, etc.).
It is like the Mac client, but that functionality still doesn’t justify the resource usage than a Chromium wrapper would bring.
Right; my point with that was more around the implication that it's just a git wrapper.
Regardless, my ultimate point is that Github went through all this trouble to make this Electron Shell thing and they don't even bother using their own tool. That seems surprising, Electron's merits and troubles aside.
Haven't tried it yet, but the history visualization looks very cool. It can be useful to actually SEE branches sometimes. As for why its not on linux desktop? Probably too much work to adapt for many different flavors for a small number of people.
As strange as it sounds the lack of a decent git GUI is one of the reasons I don't feel comfortable using Linux as my main development environment (not the only reason of course).
It's a big pitty neither Github nor Atlassian (the big "git" players, in my mind) seem inclined to release a GUI client for Linux.
I think learning the fundamentals of the git command line is pretty simple, and pays large dividends.
Indeed, learning to use git was one of the main things that spurred me to learn to use the command line for many other tasks. It's a good starting point.
I'm very comfortable with the command line in general already, and if I have to I can use git on the command line. I've just always felt a GUI is the best interface for git - personal preference I suppose.
I'm a very visual person when it comes to code, and being able to see a nice history/diff etc inline with a few clicks just sits better with how I view the world & my ideal workflow.
I appreciate I'm probably in the minority on that though, as evidenced by the lack of client from those two big players I assume they feel that way too!
Exactly, I feel the same. By default, git commit just shows me "M /src/foo/whatever", I prefer to use a GUI where I can then click on that and it shows me a nice fullscreen visual diff with colour highlighting etc. Just works a lot better for me in being productive and reviewing things before I commit(an essential part of any workflow)
I also prefer a nice visual diff and branching so usually depending on what project I am working in I always have Gitlab or Github open in my browser. Everything else is done on the CLI.
I started with GitHub for Windows and have quickly transitioned over to PowerShell. Bit of a learning curve, and I still have to look up a number of commands, but I've actually found it easier than using the GUI. I don't even use the Android Studio integration ...
Gitg (https://wiki.gnome.org/Apps/Gitg/) looks decent, although it's Linux-only. It's like git-gui and gitk merged into a GTK3 interface.
It would be cool if Atlassian would open-source their client (SourceTree). They make money off of Bitbucket/Stash and provide SourceTree as freeware, so it seems like a no-brainer to open-source it and let the community port it to Linux.
git-cola runs on Mac OS X and Windows too.
It's also very vim-ish / keyboard-centric, which is a big plus if you hate using a mouse, but still like to visually stage things.
I haven't found a dedicated Linux GUI client for git either, but I'm a big fan of IntelliJ's CVS support. While it supports far from everything you can do with git, its interface is excellent, and having it integrated with your editor is a big plus.
I use http://rabbitvcs.org/ (it's a nautilus plugin, so basically it's got the TortoiseSVN style context menu interface), and find it great. Having said that, my main work is with SVN, only use git for interacting with open source projects I need to submit PRs to etc.
I think that's a poor excuse for not having a linux version. By that logic, we wouldn't have sublime because vim/emacs should be enough.
As I see it, the main reason I like to use linux on my development boxes is flexibility(or call it freedom if you want, I don't like doing so). I can do things in whatever way works best for me and I can create scripts/install packages to glue stuff together fairly easily to adapt to my workflow.
That was rather my point. It's not that Linux doesn't need UIs because their users all use CLIs, it's that it's users all user CLIs because anyone who'd like a nice UI stays well away.
I never said anything about removing existing software (such as sublime). I was talking about there being less incentive to create a git gui for a user base that is - from my experience - happy with the current cli interface or any other already existing client (such as magit for emacs).
I'm actually working on a Github Desktop "clone" using Electron (so that it'll be "cross-platform"). I'm also working a Gtk+3 version (since I have more experience with that), but I haven't gotten too far.
Agreed. It's 2015. No excuse not to put out a Linux version. I thought those days are over. The fact that _Microsoft_ of all companies is releasing multiple developer tools on Linux these days should tell you all you need to know about this bone of contention. I'd have expected more from Github, to be honest, given Atom.
On my Ubuntu at the moment the big cross-platform packages I have are: .Net platform, Visual Studio Code, Spotify client, Skype client, Viber client, Chrome, Scrivener, …
Maybe because most GNU/Linux developers seem to be happy using it as a PDP-11 with a VT100?
Having used a multiple of desktop systems since the mid-80's, and lots of their main IDE systems, I could never grasp this attitude. And yes, I do my way around Emacs and Elisp (but it comes from MIT Lisp culture).
My guess is they don't bother with Linux systems because proper application packaging on Linux OSes is source-centric.
They've made the choice not to offer their code as free software, so that would mean it would be a headache to support on systems that value software freedom.
It's possible that since Linux is a smaller percentage of their user base that they prioritized the Mac OS X and Windows ports and will eventually do Linux. If I were them that's what I would do at least.
It's using Cocoa on OS X and WPF on Windows, in other words the UI toolkits that are native to their respective platforms. Qt indeed works everywhere, but by using it you make the tradeoff that your app doesn't really feel native anywhere (except maybe on Linux with KDE).
In short, using Qt would mean making concessions on UI quality.
I find it hard to look at their windows UI and think "native".
I'm wrong, as it was explicitly designed in windows 8's "Metro" style in mind [https://github.com/blog/1151-designing-github-for-windows]. Nevertheless, the concept of a "native" windows style is currently such a mixed mess that I can't bring myself to think of this app as "native". I don't see why being native to Metro is desirable enough to give up the convenience of having a single cross-platform app.
[I'm not saying I don't like the design, I do. It's just that I care about its features — simplicity and github integration — as something I can recommend to git newbies — much more that "nativeness".]
I don't think non-cocoa or non-WPF necessarily means worse quality, you just have to do a bit more custom work. Take Slack (using the Electron framework), or Telegram's Qt client.
Having said that, Qt Quick Controls could definitely be improved by having better default desktop QML UI widgets.
I use Slack on a daily basis and I can't say I'm happy with it being an Electron app. For what it does it's very resource intensive and the way it disregards a lot of its host OS conventions isn't cool. If I wanted a web app I'd open another browser tab; there's no need for a goofy wrapper with half-hearted OS integration.
I also use it daily, and agree with what you are saying about it being a resource hog. That said, I find it pretty good for the most part, and being cross-platform for free is killer.
I'm on OSX and Linux, most of my team are on Linux, I'm not sure they would have taken the trouble to release a Linux version without Electron.
I think the problem is that in user interfaces pretty good can be a million miles from good. It's like the uncanny valley in animation - the app feels wrong or ill but I can't quite tell why and it's very off-putting.
OS X and Linux are not the same OS. The entire stack for writing GUI applications is completely different - as different as writing an iOS app vs. an Android app. OS X and Linux don't share the same kernel, the same foundation frameworks, or the same UI frameworks. The entire application would have to be written from scratch. If they're really ambitious they could probably share some Objective-C business logic, but anything that touches the UI is platform specific.
Just because you can type "sudo" on both doesn't make them similar when it comes to making GUI applications. Again, the frameworks are completely different, meaning that a complete or nearly complete rewrite would be necessary.
Github probably considers the "depth" of git use by the average user to be one of its KPIs. Git is extremely powerful, if you are only doing checkouts and commits you are under-utilizing the tool and also underutilizing the service.
So it's smart for Github to build tools that lower the bar for a) understanding git, and b) using git's more powerful features.
Useful metrics would be things like the percentage of users who use the pull request flow, use it with at least one comment per pull request, have pull requests that get revised, etc. etc.
I'd guess that part of the growth potential driving Github's valuation is the notion that git's power features add significant productivity/value and that github is uniquely positioned to let a significantly large number of developers and teams make optimal use of those features for development and collaboration.
>a) understanding git, and b) using git's more powerful features.
But then you start talking about pull requests, which are not a feature of git. They are specific to github (e.g. try finding a PR comment in the git repo).
Does the new tool help with advanced git stuff, or does it just serve the github workflow?
The pull request is just an alternative version of the patches linus used to receive via email. Git is equally well suited to both.
At this point I don't think the tool does all that much advanced stuff, but the focus appears to be on understanding git at a level required to understand the more advanced features... so actually more focused on the semantics of git than on specific workflows.
I'm a beginner here so sorry for if it's a stupid question. I work with GitFlow and the only things I use are commits and checkouts, but for what do you use Git?
About which powerful features are you talking about, does anyone have a link with some more in depth informations?
Some features I use: Cherry-picking commits across branches. Merging branches. Rebases for forward-porting your work onto a new upstream. Bisects for determining which commit introduced a bug. Push/pull for sharing. Format-patch for sending patches around. Submodules.
If you want to get a deeper understanding of what git's doing, read gitcore-tutorial(7). It's pretty easy to understand git's internals, and once you know them, it's easier to understand what the user commands are actually doing. Then, if something goes wrong, it's much easier to recover.
I am a guy who usually puts too much info into commit messages instead of code comments. Git blame recently helped me to find out why I had added a particular line to a lengthy if condition.
As with many svn features, blame requires access to the server and is also quite slow. In git, this sort of thing is instantaneous and therefore viable to do all the time if you like.
I think we use a lot of PR flow in our team. It's really powerful if you collaborate or plan to collaborate with others as it allows you to get together and look at the commits to ensure code quality (in theory).
Even the command line git itself is really nice because it gives you the current condition of your repo and suggestion on what you can do next. You have changes, if you want to commit use this command or if you want to add use this command.
there are many 'minor' features that are occasionally useful.
For example, when you make a stupid mistake, reflog can make you gain a couple of minutes.
While I find this initiative fantastic, it's a bit frustrating that Github, a company that lives on source code being open, does not publish the code of tools like this one.
I don't mean this as a knock on Github, but I'd argue they are a company that lives on selling corporate licenses and enterprise software to companies that don't want everything to be public.
Correct. They earn money off of private repositories... not sure how them hosting public projects adds directly to the bottom line besides the obvious marketing benefit and sticky factors.
not sure how them hosting public projects adds directly to the bottom line
They get a ton of feedback and insight from non-paying users. The usage and feedback can drive both the product and business roadmap for their enterprise offerings.
Every developer who enjoys using it for personal or open source is also likely to recommend it to their employer as well. I know I have helped drive adoption in a few organizations.
Github lives on companies and individuals that pay for private repositories hosted on Github's proprietary (read: not open source) software-as-a-service hosted infrastructure. While git itself is open source, almost nothing else that Github does is open.
I consider these kinds of companies 2nd Generation Open Source companies ... whereas the first generation of open source companies had an open source product and made their money off maintenance, the 2nd gen often have a bunch of components that are developed open source, but sell a closed source glue/package of all those components.
Companies like CoreOS, Mesosphere, all fall under this umbrella, where you could technically glue all their open source components together to form their main product, but it would take you quite a bit of time to support.
Github is sort of like this. They contribute a ton to open source, and are built mostly out of open source components (that ARE open source). But their website is really just a glue to all their infrastructure, and that's closed source.
That's a really great summary. It's an interesting alternative way for companies to produce a fair amount of open source contributions and still make money. I can definitely see this with other companies including ones that specialize in continuous integration and other services that developers are interested in.
> While git itself is open source, almost nothing else that Github does is open.
That's not true, they have lots of open source projects under their organization: https://github.com/github. It's not enough to build your own GitHub clone, but some significant parts are being developed in the open (jekyll, hubot, linguist, ..)
This is true, but I think the amazing thing about free software is it is free to use however you'd like. Just like free speech, sometimes the outcome of FOSS isn't completely desirable.
Again, lots of good has come from GitHub, not limited by:
It's surprising that a closed source company can be so successful with open source developers. The reason is because it's free for open source projects.
EDIT It's the same motivation
as Oracle's recent "reverse engineering" drama, they don't want you to have the source.
Will this end up true: those who sacrifice freedom for free deserve neither ?
[BTW: Franklin's "essential liberty" was actually self-government requiring taxation - like github charging; "purchase a little temporary security" was gifted funds for defense of the frontier - like donatiomware (e.g. OpenSSL after heartbleed).
https://www.lawfareblog.com/what-ben-franklin-really-said
]
You could also say that it's ironic that people who are concerned with openness of source code would choose to host it on a proprietary platform. But hey, it's super convenient. (I do it too, but let's not kid ourselves.)
Both open source and close source have their place, and a bias towards either should be avoided. It frustrates me that so many view the two as mutually exclusive company decisions.
Necessary but not sufficient. There would be no free GitHub repos for open source without the income from the closed source repos that pay for them. As usual, open source is subsidized by closed source.
Maybe not "github" repos, but other public git repos would pop up. Suggesting that open source wouldn't have distribution is ignorant of the origins of open source.
This is a straw man. I nowhere suggest that open source would not have distribution.
GitHub isn't just 'distribution' it has required a huge amount of investment and focus by individuals who need to make money to feed their families and prosper.
The fact that it is GitHub that we're talking about, and the fictional repos that you imagine would spring up proves the point - in the real world, open source is subsidized by closed source.
SourceTree is really nice overall. To name a few things, I prefer its view of history, its hunk selection UI, and its commit message box (GitHub's is tiny and can't be made much bigger). It's also nice that it supports Mercurial.
I had some problems with it keeping changes synced with the file system, though (on Mac OS). E.g., I'd change something in my editor and SourceTree wouldn't pick it up until I reopened the repository in SourceTree.
I also prefer a single window like GitHub's app, but that is a minor annoyance. The non-syncing made SourceTree unusable after a while, and I went back to GitHub for Mac.
I wish Atlassian would put out an update, because I'd prefer to switch back.
Every week or 3 when I restart my machine and reopen SourceTree, it tells me that there's an update. Maybe the issue that you're talking about hasn't been logged or they're not working on it.
I'll try GH Desktop, but for the past few months mine's been broken where it loses my repos, so I've been using ST exclusively :)
Are you on Windows? I'm pretty sure the Mac version hasn't been updated in quite some time. I just downloaded a fresh copy, and it's the same version I downloaded a while back: 2.0.5.2.
Having used both on a Mac (where I mostly end up using the CLI anyway), I'd say that SourceTree is what you want to use for stuff like code review, whereas GitHub (other than local merges being hard to figure out - see my other comment) is quite neat and uncluttered - perfect for small projects or if your workflow revolves around their public repos.
(I don't see why this is being modded down - is it because I failed to mention I'm also using it in Windows?)
I use SourceTree full-time but am keeping an eye on GitUp[1]. The UI is not quite there yet IMO, but it's insanely fast and I love the focus on keyboard shortcuts.
You can however add most 'non-dumb' features you need as custom actions so it's only two clicks away. Now they just have to add customizable keyboard shortcuts and I'd be all raving about it, but still I use it everyday mainly for the staging area.
Is this related to the recent Github For Windows redesign? It used to be a great product, but the last version made some really odd UI changes and the whole thing became 10x slower.
Github For Windows used to be as important to my workflow as my code editor. I absolutely loved the "click to select which lines to commit" feature, and I'm pretty sure it improved the quality of my commits drastically. And it was constantly improving.
A few weeks ago came a new version that changed everything. Previous updates used to be incremental, but this one seemed to replace everything at once. Overall the UI was still good, even though important parts became hidden behind tabs. But the performance... Oh god the performance. Syncing repos became a multi-minute operation. Listing commits went from instantaneous to taking several seconds. It became so unusable I switched back to Linux for development.
The Windows app is still WPF-based and still uses ClickOnce for its installer. The web page claims that this is a new unified app, replacing GitHub for Mac and GitHub for Windows. But it seems to me that there are still two separate apps. I had expected something like a desktop app using web technologies via Electron, like Atom.
Please no. GitHub for Mac is an extremely solid, smooth, light little native app and I would hate to see it vanish in favor of a heavy chromium-based monstrosity. I don't use Windows but if I did I'd prefer a WPF or .NET app over a chrome wrapper there, too.
Common core+separate native UIs will always be the best sort of cross platform app in my eyes.
I'm sure you're right about a native Cocoa app feeling nicer than a Chromium-based one. But on Windows, WPF is notorious for poor performance; a Chromium-based app might actually be better on that platform.
You're right, of course. My comment was premature. But I've looked at both the Windows and Mac apps now, and as far as I can tell, there's no common core besides (probably) libgit2. Each app is implemented using a language runtime and frameworks specific to its host platform. So any unification is only skin-deep. Maybe I'm just envious of companies that have the resources and discipline to keep up the appearance of a unified app while in fact maintaining multiple independent implementations. FWIW, if I were going to implement a unified multi-platform app, I'd use SWT; in fact, I did on a recent project.
When I saw "Desktop" in the name, I was really hoping this also brought some of the web features to the app. Things such as being able to view/edit the wiki, or issues of the repo. I wonder if that is in their long term plans for the app at all? That would be really awesome.
Github for Mac is quite good already for commiting and pull-requesting. I could stop using my browser (for Github, at least) if they put issue management (open, close, view, comments) in there too. Would be awesome and a more unified experience.
The wiki is just a git repository of markdown files. You can grab that and use a local text editor if you want, though that's not integration with the app (but I'm also partial to using the command line).
At this time, we're focused on optimizing the Mac and Windows experience. We're always thinking about potential improvements for the diverse needs of our users, though!"
Most Linux users are going to be inclined to use the command line. Even with these new additions GitHub Desktop's features are much smaller than what is possible with the command line.
I'd love to see more development in the Git GUI space; a GUI really enabled git adoption and comprehension on my team. SourceTree has been my go-to for over a year now and it generally gets the job done, but it can be flakey at times (on Windows) and it seems like Atlassian has taken a hiatus from active development. I hope Atlassian takes up the reins again - this tool is pretty essential for me and I'd be happy to pay for it.
I'm Tim, a dev at Atlassian. I just thought I'd chime in to let you know we are absolutely taking up the reins on SourceTree again! In fact, we're in the process of growing out our team. You can read a little more about it on the ST blog from earlier this year: http://blog.sourcetreeapp.com/2015/02/25/were-just-getting-s.... We are aware of the performance issues affecting Windows users with certain repository shapes and have our backlog prioritized accordingly.
I haven't had much of a chance to play with GitHub Desktop yet, but it can only be a good thing for the users of all Git clients - nothing like a bit of healthy competition :) However, SourceTree's focus will remain on providing the best possible experience for professional teams using Git (and Mercurial).
>> SourceTree has been my go-to for over a year now and it generally gets the job done, but it can be flakey at times (on Windows)
I've had the same experience. SourceTree has gotten better since I've started using it, but I frequently get hangs on commits and pushes on one of my machines. So much to the point that I downgraded to an older version of SourceTree.
One of the only things I miss after switching from OSX to Windows last year is Gitbox - http://www.gitboxapp.com/ - it's not free, but for what I do, it really did the trick.
This new desktop version of Github looks a lot better than its predecessor, but I need to play with it more. It does feel a lot more like Gitbox to me than SourceTree.
I've heard numerous times that Linux's lackluster popularity is due 'chicken and egg' problem in the application space. If a company that gets the maximum possible percentage of Linux users is not willing to support the application for Linux then we can't expect anyone else will even attempt. May be because Linux users are 'smarter' and better off with CLI ;)
I use git primarily on Linux, but I don't use an IDE. I frequently use 'git gui' to prepare commits - I particularly like the ability to select individual lines from a diff to include in a commit, breaking apart multiple changes to the same file when necessary. I also use gitk a lot. I'm very comfortable using the command line, but it's not correct to assume that command line users wouldn't want a GUI tool as well.
As a Linux user: I very much would at least try it. Magit works great for the git repos themselves, but when I'm on my work machine (a Macbook) I tend to use Github's Mac client in order to handle things Github-specific (particularly cloning and handling pull requests).
Well, to be honest, as a Linux user, I would definitely consider using GitHub's own GUI application instead of some application developed by a third party.
They don't participate in the open source community. They're similar to Apple in that they take open source stuff and build a closed ecosystem on top of it.
GitHub has 6 pages of public repositories (https://github.com/github) that you can peruse. To pre-empt your response, yes, they aren't all open source projects that GitHub has released. But a great many of them are. Some of their popular projects include things like Atom, Hubot, Boxen, Linguist, and many more.
They also have developers who contribute to a great many other projects as part of their daily work; Ruby springs to mind - Aman Gupta and Charlie Somerville have contributed quite a lot. And they pay at least two people to work effectively full time on git itself.
At least the #2 and #7 (by number of commits) committers to Git are employed by GitHub. They're both very consistent contributors and have been for a very long time.
You specifically said that GitHub does not participate in the open source community and I think I've amply demonstrated that you're incorrect. If you'd like to continue to argue the point, I'd appreciate some facts.
You're right, they hired people that were already participating in the git community to continue to participate in the community. This is better than nothing because it ensures that they are employed, but it's a net zero effect for the git community and isn't what I would call participating because they aren't bringing anything new to the table.
It's similar to Microsoft hiring a bunch of Linux developers to continue developing. Yeah, this is good for marketing checkboxes of 'supporting the open source community', but from the perspective of a developer in that community, it's worthless.
What would be nice is if they hired new developers to work on git so the community actually grows and gets something.
I don't know why I'm responding, but I can't help myself. I guess it's the good old XKCD "Someone is wrong on the Internet" effect and I should know better. But.
They are paying people who would otherwise work on Git in their spare time to work on it full time. That is a net win for everyone who uses git.
I'm going to give up at this point and just accept the fact that you're going to spin it such that any commercial entity that uses open source and doesn't open source their core product is a parasite. I think you're wrong, but you're certainly entitled to your opinion.
No, they were both appeared to be working full time on git before (based on commit activity). They just changed 'sponsors' i.e. employers.
These aren't my own facts. This is based on what I've seen with open source contributors for a long time. Rather than companies contributing code or their own engineers, they just hire an existing contributor to keep doing what they do. I'm not arguing that this is bad, I'm saying that they should be put on a pedestal for essentially throwing money at something that they depend on anyway.
I see I've struck a nerve with github fans, but be honest with yourself. Do we say oracle is a great open source contributor because they have java language devs?
Wow, someone who worked at github extolling the virtues of github. What a wonderfully objective view.
Lots of companies throw money at some open source developers to continue developing what they were already doing. That doesn't make the company any more open source friendly. It just makes them a funding source for people doing the real work.
Contrast that with a company like Red Hat that bases everything on improving and supporting open source. People used to give them crap for RDO, but that's nothing compared to closed ecosystem github built on top of open source.
Github is just as supportive of open source as Stackoverflow (superficially). They just get a lot of credit by association for real open source products hosted on their platform.
They're similar to Apple in that they use open source in their private ecosystems and also contribute stuff back to the community, just not their entire product. Apple has open sourced Bonjour (zeroconf), Webkit, LLVM, libdispatch, etc. Github has open sourced Atom, Jekyll, have contributed to lots of Ruby/Rails projects, etc.
My initial impression is that I like it, but I'm confused what "git sync" is. I've never done a "sync" before so I'm uncertain what will happen when I click the button.
Seriously, I get it, people don't love git's choice of verbs and syntax. Picking different ones arbitrarily helps no one however.
I'd say that part of the problem is that there is no "right" way to develop for Linux. There's a multitude of choices available at every turn when developing software for Linux, and while this is its strength, it's also its weakness. On Windows and especially OS X there are established "right ways" that can easily be deferred to.
Trying to provide support for Linux software could also potentially be nightmarish given the innumerable factors at play. There's no end to the number of ways any given Linux box may be set up.
Can you give an example of what the 'multitude of choices' is please?
I hear this often about Linux and don't really understand what people mean. Interested to hear someone else's perspective.
From my perspective, there are options in the Linux world but a pretty clear beaten path of common choices. The one choice you have to make is the toolkit - QT or GTK+ - but that seems like it. In terms of things like sessions, caching all the distributions follow the same standard (e.g freedesktop.org)
The problem with Electron (and other Chromium/WebKit wrappers) is that they produce apps that are a lot heavier than those built with native UI toolkits (Cocoa, Qt, GTK+, etc). That might be ok for some types of apps, but I wouldn’t want a git client that requires resources on the order of a Chrome tab (300MB+ memory and high CPU usage).
Maybe if you're deving on linux you just want the CLI anyway? I don't know if I'm abnormal or not, but I've _never_ wanted a git gui and really don't see the need for it at all.
Ya, CLI is great but for people like me who mix both ( like using gitg for committing ), GUIs could be handy. There are lot of Java (or Android) developers who don't want to switch to Linux precisely for this reason.
But those Java and android developers will use android studio, IntelliJ or eclipse, which all have good guis. I don't see how that is an issue in this case.
Yes, the mobile web interface is quite bad. I mean, it's not horrible; it does the most basic things, but it requires more than one click to see very important things, like commit messages.
Can I do anything with this that I can't already do from the website, or is it just the same tools with a nicer native UI? In other words, is this somehow bridging the gap between the site and the git CLI (which could be useful for some of my less tech-savvy collaborators)?
What's the advantage to SourceTree? aside from nicer ui.
I wish it had the code review, commenting, issue tracking of the web app in a desktop application, all in one place. It's a pain to move constantly between the editor, CLI/SourceTree and Github web app for everyday tasks.
I'm using this new client against Bitbucket right now. Just added local repos that I had already cloned, and it's just following the .git/config like any good git client does.
I've been using Github on Mac for a while now. It won't do all the fancy things that the CLI will, but I love it for the ability to break up large bunches of files into separate commits, for when I forget to commit for a while or my local repo gets a little messy.
So does anyone know what they used to build the 'unified' app UI? If I remember rightly they used WPF on Windows in earlier versions. Is the UI now abstracted using a third-party framework/inhouse framework?
I've been using the beta for a while and have found it to be quite nice.
Simple operations are quick and intuitive. If you need anything more advanced, a git shell for the current project is just 2 clicks away.
Having all the visual diffs readily available in the client before committing is quite convenient, as is being able to push your branch and open a pull request for it at the press of a button.
I'm hoping issues and PR management is next on the plate. You can open PRs from the client right now, but to review and merge them you'd still need to open a browser.
Hasn't this been available for a while now? I know I'd been using it for at least a few months up until recently. I made the switch to Sourcetree the other day and haven't looked back. I never realize how infuriating not being able to see changes in a repo at a glance without clicking into it was until I suddenly could.
Can't speak to any more advanced differences though. I'm still very, very new to git.
What to do with the scary message? Does this affect the OS version of git or just the version that this Github application uses?
OS X 10.9 and later includes Git, so GitHub Desktop will no longer install Git as part of its command line tools.
The version of Git you have installed through GitHub Desktop is no longer supported. It's recommended that you uninstall it as soon as possible.
I wonder why, after downloading and installing the GitHub Desktop application I should use my GitHub account and password to connect the client to GitHub (with no other way available)?
Would it not have been better if GitHub Desktop was a seperate application that gets permissions (for example via OAuth 2.0) as an application in the "Authorized applications" section of the GitHub profile?
Took me a while to figure out how do do them via the UI, it's not immediately obvious that the side pane (which tries to take you to the web site for submitting pull requests) has nothing to do with local merges, which are now accomplished via an option that only appears when you're comparing branches (on the new timeline/graph thingy).
There doesn't seem to be a way to do so, but if you open a repository cloned elsewhere everything works just fine. It even prompts for your Bitbucket password if you try to push.
Yea, I was using Github for Mac previously, and all of my non-Github projects ported over to the Github Desktop app. Like the other reply said, you just have to manually clone and the 'Add' it.
Just downloaded it and tried it out. Looks pretty nice, but the history view isn't populating when I try to use it for github enterprise projects (I did login successfully). I'm just seeing a completely black rectangle and no commits.
One theory I have is that our default upstream branch isn't master, but I'm not sure where to set that in the app. Anyone else noticed this?
Well, that update turned the app into flickering, unresponsive mess on my Mac (10.11). And I have to use some sort of old school contact form to report a bug to GitHub? I'm a bit incredulous.
I like GitHub for the basic "see what you're committing and commit it" work flow, using the command line otherwise, but I suppose I'll switch to Sourcetree for now.
I really like the GitHub desktop app. Although, I honestly I could care less about the fancy new graph feature. I would rather they had added a couple of simpler, more useful features:
• the ability to organize repos by organization or with custom folders/lists
• the option to open a repo in a new window by right-clicking on one from the list in the left column
The client itself is very streamlined. Push/Pull operations are swept into a single Sync operation. Merging is as easy as selecting a branch from a dropdown and clicking a button. Things like that.
On the downside, utilities like tagging, blame and stash do not seem to exist. The account linking system from the old GitHub client hasn't changed and you can't clone from anywhere that isn't GitHub. Revision history is a bit ~too~ simplified and you can't really see at a glance what branches are deriving from where, and you can only see the history of one branch at a time.
I'm sure newbie developers on Github might appreciate the simplified UX/UI, but it's missing a ton of features that are useful in an environment with multiple devs.
It has been out for a while (I guess in beta form), atleast for Windows.
Still using GitExtensions. This has a nice interface for hobby projects, but when working with "enterprise" huge projects at work - it lags noticeably.
those wankers should work on getting diffs to actually show on their site.
hate when i have to code review some contributor and the site just says "oh, i will not bother showing any change on that file"... so i have to download their branch, run diff on the awesome `meld`, which kicks their visualization anyway, but then the only good thing about github: inline comments on code reviews... goes away. i have to either email or add lose comments on the code review panel with what i think.
but hey, now we can have the same crappy experience on (selected) desktops! hooray! well, at least you managed to get me to write an offense on a public forum. that is something. you wankers.
