I hate all the visual clutter and unjustified complexity the new stylish iOS-like interfaces bring. Those interfaces are only good for Twitter and friends (and for screenshots).
Have you tried GitX? What you described seems a bit more like GitX than what GitHub is trying to do here.
When I first fired this up, I made a tarball of one of the repos I'm currently working in (it has uncommitted changes) and started clicking around. I'd do something in the GitHub app, then go back to my bash prompt to see what happened. I was pretty confused when I switched branches and all my changes were gone. Then I went back and read the blog post. It auto-stashes when you switch branches. I also wondered what the heck the "Synchronize" button does, so once again, I referred to the blog post. It performs what they call a "smarter version of pull --rebase && push that reduces merge commits but doesn't rewrite your merges". Oh, really?
At that point I realized that GitHub has done the hard thing. They haven't re-created the git CLI tool in a GUI, they've created something different. They've created a tool that makes Git more accessible. Little things like auto-stashing when you switch branches will confuse git veterans, but it will make Git much easier to grok for newcomers because of the assumptions it makes about your git workflow.
I see great things in this app's future. It's probably not for everyone. If you're a proficient git cli user, and you like it that way, then you're probably best off sticking with what you've got. Maybe explore some of the more traditional Git GUI clients like GitK or GitX, but keep in mind, that's not what this is.
Nothing in your reply addresses my points, so I'm not sure what to answer. Yes, I tried GitX, and I'm not looking for (or using) Git GUI tools. This doesn't make GitHub for Mac less visually cluttered.
I'm mostly discussing GUI trends (as a Mac developer who cares about this stuff), using GitHub as an example (which, as you say, gets job done great, but I say that it can be improved).
Clutter means (let me open the dictionary) "a collection of things lying about in an untidy mass".
I never said only spacing produces clutter. Either I'm not explaining myself clearly or you read something that was not in my comment (this is called a strawman, right?)
You mentioned visual clutter, and then your first bullet point was about too much spacing. Clutter--according to the OS X dictionary you cited earlier--refers to a jumble or tangle of items, implying that they are close together. That's the discrepancy he was referring to.
His posts were completely non-hostile, so aren't you overreacting?
I didn't mean my reply to be a point by point rebuttal. Your description seemed to match GitX pretty well, so I figured I'd mention it.
The rest of my reply was pointing out how I perceived this to be different than GitX, which was tangential to the point, but I didn't really think a separate reply was required. Sorry for the confusion.
Part of the reason is that the commercial clients have finally eclipsed gitx in power, ease-of-use, and prettiness.
Notably, SourceTree (what mainly use) and Tower (if the incomprehensible one-repo-at-a-time limit isn't a dealbreaker) now compare favorably to gitx in most ways.
So I don't recommend gitx anymore, but from what I hear Gitx (L) is a fairly active and popular fork:
Been using that for a few weeks, it's great. I previously used brotherbard's experimental branch from github and he told me about it.
I use GitX for committing and browsing and the command line for the rest. None of the GUIs have blown me away yet, but deep GH integration is a big plus for me so GH for Mac might join my workflow.
Git seems to have broken down the social contracts around forking that kept most opensource projects cohesive. Unless the project has a great deal or inertia, it is difficult to remain the canonical source, and the project effectively disperses.
You're not wrong but I'd say the degree to which it has eliminated forking costs far outweigh the occasional confusion.
If you think about it, this is basically 1) a marketing problem and 2) would be solved instantly should GitHub introduce a better 'network' visualization.
I think it is worth mentioning that while the GUI could use a few tweaks, the overall user experience was amazing. And got right a number of things that were hard or tempting to get wrong:
1. Let me enter an email address separate from my GitHub account.
2. Automatically found git repos on my system. Let me pick which ones to use.
My only two requests are:
1. Show untracked files the way git does, where if a whole folder is untracked, it only shows up in the list once, rather than showing every subfolder and file inside it.
2. Handle submodules better: let me see the submodule changes in a commit, let me browse and commit submodule changes and the commit the parent.
Agreed—the concept of porting UIKit to OS X is insane to me. The Mac desktop is not an iPhone! I don’t want to interact with a desktop app as if I were on a phone—especially not an app that I’m ostensibly supposed to use for development.
That said, creating a desktop interface for GitHub is a brilliant move. Bravo!
FWIW, I disagree that windows should freely proliferate. I prefer apps that stay in a single window.
I think there's a misunderstanding. I'm not against single windows, I'm against making me navigate through screens when it's unnecessary.
Also, you should let some of that angst go, because it's clear that Apple is anticipating an iOS experience on the desktop for a long time coming.
Apple is anticipating better GUI experience. It doesn't mean that they'll make all apps occupy a single window with a single task shown at a time. Notice the difference between iPhone Mail and iPad Mail clients.
1. Floating inspectors drive me bananas unless they can be pinned in the app "wrapper".
I'm with you here, mostly. iCal's switch from sidebar in 10.4 to popups and floating inspectors in 10.5 is painful. On the other hand, Acorn's floating tools window is good.
2. A new window for every document makes me crazy, because I like to use tools like Witch for doc-level tab switching.
I'm not so into tabs for documents, but can't live without them in browsers.
3. The push away toward full screen apps and in-app file management is, IMO, a good thing.
And yes, and no. It depends, as with other points. I'm glad that now Mac apps are not locked into multiple windows/floating inspectors for everything, but "you have a single window and you can look only at one thing at a time, deal with it" is also not the panacea.
1. Floating inspectors: Inspectors in general are getting better and I definitely prefer when it is well integrated into the view without interrupting my flow. They have a good start; further work is needed (not sure what though)
2. I think even tabs are a mistake now. We learned a lot from iOS about how to well integrate multiple views into a seamless interface. Tabs are kind of unnecessary imho now; we need something better.
3. Full screen isn't what I think the best aspect is - we do want to be able to view different apps at the same time. Case in point:
- I have this chrome tab open on the right hand side of my iMac monitor
- 3 terminal windows on the left hand side
- My vc pitch in PPT on my second monitor's right hand
- My PPC ad management software open on the second monitor's left side.
Restricting to one screen for an app isn't the right way I think, but an in-between method is. Funnily enough, I think Windows 8 almost nailed it.
As for in-app file management: YES. iCloud, Dropbox and a myriad of other systems all working together have such potential. I can't wait.
Yeah, right. Remove all the whitespace. While you at it also make fonts smaller so that you can cram more data into the same space.
Some people actually like interfaces to be aesthetically pleasing. And whitespace is one of those things that really helps to make ui usable and clean.
There are windows on macs, but it appears Macs are going away from them with the full screen apps. Look at all of Apple's apps - they're all going single window. Document based apps can still have multiple windows, but everything is self contained.
I don't see what's changed in 10.7 regarding windows. Can you point the app that had multiple windows, but moved to something else?
But you're right that you can avoid using multiple windows in the app if it's good for usability. My point is that currently it's not possible to have two repositories opened simultaneously; especially since on OS X it's difficult to open two instances of the same application.
(As an example, in Mail you have previews in a single window, but you can also double-click the message to open it in a separate window).
"This layout provides virtually all operations within a single window, such as editing files and project content, filtering in the detail view, viewing the build results and build log, and debugging".
I don't see what's changed in 10.7 regarding windows. Can you point the app that had multiple windows, but moved to something else?
Other than the APIs for fullscreen support, there's little that can be said without violating NDA. Other Apple applications have gone single-window over the years; Logic merged its windows two major versions ago, and Final Cut Pro X just did the same.
Steve Jobs has always preferred single windows. Before OS X 1.0, the toolbar button was instead a toggle for single window mode.
I disagree. The interface right on target for the operating system they're targeting with this app: OSX. It sounds as though you're suggesting they build their UI for another OS...
Sounds like a GUI just isn't really your thing anyway; that isn't a bad thing as the command line interface is very good.
I think overall this is a very nice product, even though some of the loading is a wee bit slow (even on an i7 iMac). It adds a very nicely done, easy to navigate interface for the times I want to visually manage stuff.
9/10 times I'll use the command line to do stuff, but this makes other aspects of code management go much quicker for me.
It seems clear that GitHub's goal is to make git useable. I'm super excited about everything they can do in that direction. Git's underlying model is fantastic, but it's UI is lacking. Bravo GitHub.
Sorry - I deleted my replies as I really don't want to argue about UIs. That was not my intention. I must remember for the future that text without tone often does not convey one's intention. This program is great, thank you GitHub.
and the beauty of CLI is that, unlike with a GUI, a CLI can serve as both a human UI, and a machine UI or API. and it does the latter for free. give me a binary-only program with a CLI interface and I can build other things on top of it, put it into a pipeline, turn it into a cronjob, etc. give me a binary-only GUI? often nothing you can build on it
You can automate GUIs using accessibility controls and/or desktop message bus. If an app is modular, as it should be, it does not matter one bit how many UIs it exposes.
Also all CLIs are not the same — try automating ncurses application.
That's cool and all, but a Windows client would make a lot more business sense. There are already a couple of nice git clients for Mac. There aren't for Windows.
And I assume github is targeting SMB with its paid offerings. Unless you're a design shop or a hip startup, odds are you're not running OS X. Based on my unscientific data, most companies have the devs working on Windows (or occasionally Linux).
They are the latter. Welcome to the San Francisco bubble, where you think everyone uses iPhones and Macs, because in your world everyone does. It's the same reason Twitter has a Mac app but not a Windows app. They build these things for themselves (and arguably they should).
They probably all use macs though, why not develop first for something you understand well and can immediately put to use yourself. It probably started as a fairly experimental product, now that they have a version out and a clearer idea they could more easily tackle a windows version.
You're not describing a bubble, "making something I want" isn't some outlandish absurd thing for developers and designers do. Bubble is rapidly outpacing pivot for most misused word.
I feel like I must be missing something here; how is the 2/3rds that don't use Mac OS the smaller market?
And as others have pointed out, the market doesn't just consist of GitHub users, or even Git users. In this case, it's developers who use an RCS and need a good desktop application to go with it.
In any case the point may be moot; judging by the rest of the comment you quoted they're not ignoring other platforms at all but rather just using Mac OS as a first step, which I can understand.
Twitter has a Mac app because Loren Brichter wrote a fantastic one and Twitter bought it (and Loren too). I'm not particularly aware of the state of Twitter on Windows, but I find it plausible that there is no single excellent Twitter app that Twitter wants to buy (or if there is an excellent one, maybe they don't want to sell).
But I just switched from self-hosted SVN to Github and it was painful for our Windows devs. Offer a stupidly easy upgrade path from TortoiseSVN to Github and I would have joined a long time ago. In fact I'd pay extra for that. I think I am not alone.
How do you know they didn't research their user base and find out that more people used OSX than any other OS?
I can honestly say I do not know a single dev who uses windows for development, everyone is on Linux or OSX. My unscientific data is probably as good as yours. So I wouldn't be surprised if they looked at their browser data and realized OSX was a pretty big market.
They're eating their own dog food. Maybe they're making it because they want to use it themselves first. I'm sure they're heavy users of Git, and it would probably be easier to do iteration on something you use instead of iterating on something you'll never use (on windows).
My point is that their UI could change, and it's easier to test out UX on something that you'll use everyday, than on something that you'll never use. They made Github because they wanted to use it themselves, not because they saw it as a money making scheme.
For productivity apps (and especially developer tools), it's not worth chasing customers on a platform you don't love -- you'll do a bad job and you'll be unhappy doing it.
And as Mac users, they may be consciously avoiding the reverse of an all too familiar situation, where non-Mac-using Windows developers shoddily port their app to OSX.
Selling software where the target market is exactly the same as the people writing it seems like it's the exception not the rule. I assume most OpenTable devs do not own a restaurant.
Narrowing yourself to 'git users' is a silly thing for two reasons:
1) there are many Windows devs out there who require a VCS
1a) ...who will only use a GUI-based VCS (seriously)
2) there are many users of other VCSes (e.g. Subversion)
These are big markets waiting to be tapped. The answer is not "don't try if nobody else is tapping them". Hacker News is the last place I expect to hear that!
I think it's a massive opportunity. These people are using Subversion because TortoiseSVN is a nice piece of software, not because they are anti-DVCS partisans.
If someone made an app like Tower but for windows and charged $50-100 for corporate licenses, they could make a killing.
Or, if the Github team, having first created a GUI for Mac, which they use themselves and can more easily test, were to then create a Windows version and charge $0 for it, they could convince a lot of Windows Subversion users to switch to Git and Github, paying monthly for private repos.
github should do some os fingerprinting of tcp connections to its servers and they'd be able to tell fairly accurately what most of their customers use.
Judging by their use of chameleon, and their general UI choices, I think we can expect an iOS client from github as well in the future (using the same codebase as this desktop version). I think that OSX + iOS > Windows users in that regard.
We chose Chameleon because it provides for an awesome layer-backed environment to code AppKit in.
Everyone's all cuckoo about Chameleon because it lets you port iPhone apps — but the real win is a fully layer-backed environment with modern APIs (UIKit).
Our decision to use it has nothing to do with iOS at all.
I'd say the choice of Chameleon was driven by them wanting it to look "modern" or iOS-like. A native Git/Github client like this doesn't make sense on a device where you can't develop code (except in the web browser with Cloud9 or something).
In respect to the Windows question, I wouldn't be surprised to see them ship one in a few months, once they iron out the bugs and determine exactly which set of features a native client needs to provide.
I'm not so sure of that. If Mac is still the hacker (pg hacker, not New York Times hacker) platform of choice then there may be at least as many Mac users if not more.
Mused on Twitter earlier about this but got shot down by @kneath.
Thought it was interesting that Hubcap was in the first screenshot on the blog post and @kneath himself was a backer of the project, meaning that he's had an inside look into the development of Hubcap while they've been creating Github for Mac.
Conspiracy theory I know, but I thought it was interesting at least.
How much of the client is GitHub specific, and how much is plain 'ol Git? Does it make sense to use it w/o using GitHub?
Couldn't find that info in either the announcement post, GitHub for Mac page, or the 118 comments so far here, and don't own a Mac so can't try it for myself (still would like to know whether to recommend to other people or not, though).
You can certainly use the client for plain ol' Git. The GitHub-specific stuff is a "Push to GitHub" button on repositories that aren't already on GitHub, and a list of your GitHub repositories.
It's more than useful without ever using GitHub the web service/site.
I wonder why they've released a client for OS X and not another OS―if anything, Windows is pretty lacking in git love.
Whose is its target audience and the desired function? New users, to reel them in with a shiny UI? Or established users who don't use it much, to make the experience simpler? (And if it's established users who use it much―isn't the command-line faster for them?)
If they want more users to use GitHub, surely a GitHub for Windows makes more sense (unless this is an employee's side-project gone primetime).
I agree. My command-line experience is faster and keeps my work flow the same whether I'm developing on OS X or Linux. The added GUI would serve to slow me down but if I really wanted to see changes visually, I could just go to github.com and do everything I need there since I know where everything is.
The Github guys just never cease to impress me. They've made development so much more enjoyable. And at any given time, you can expect them to not only do the right thing, but to do better than that. Like, releasing a great Git app for free, hoping to get more people to use Git, and thereby Github, and thereby becoming paying customers. A perfectly reasonable plan, but most companies don't have that foresight and patience. My hat is off to you, you rock.
The CLI_FU's are just becoming more and more useful (and paid more). GIT is just becoming more and more useful for everyone from writers to designers. Those groups of people usually run with their tails between their legs away from the command line.
First time an application has been unsupported on my Core Duo (32bit) Macbook Pro. Is there a reason for it, does the application really require a 64bit OS, or did the GitHub guys just forget about us early Intel Mac owners?
What a great "out of the box" experience. Unpacked it, entered my github login data and synced my repos. No hassling with ssh keys, no setup, no other questions asked.
Not that this contributes much to the conversation but: YES on both counts.
I use GitHub's issue tracker in volume both for some fairly large projects (getcloak.com, walkscore.com, and wherebe.us) I've found that the Issues web interface leaves a lot to be desired. It's a fine v1 [v2 technically], but somewhat painful in practice once you have more than a handful of issues. The 280 North issues app was interesting but hasn't kept up with the latest GitHub features.
There are already plenty of okay Git GUI clients out there to manage your repository locally, but what I miss is the ability to edit (and preview!) the wiki locally. You can sync the contents via git, but then you are left with editing the raw source files directly.
Still extremely buggy, I was only able to load one of my repos, others failed with error messages like this: http://bit.ly/iJzNmp and even the successful ones came up with errors after loading.
There is really no need to use a URL shortener when posting links here. The HN software will abbreviate the link text on it's own if it is too long. It's a little annoying to have to guess where a link is going to forward to.
GrabBox automatically shortens my screenshot links. Click if you dare. IMHO they should have used bitly pro and their own shortener for marketing the thing.
While it's beautiful and a great first version, I don't think it really provides anything that GitX doesn't already do better. I can see how this tool might be valuable for someone who's intimidated by git, because it's hiding a lot of what's going on. But in it's current state I wouldn't use this for more than training wheels. If / when they add pull request support and other Github specific features I might come around.
How does this compare to Tower? It's not obvious from the website, but I'm guessing is less fully featured. Anyone with experience with both who can comment?
I have been using Tower almost daily since it was released in beta some months ago.
The feature set it comparable, with the biggest missing feature being individual file rollback. Tags and stashes, as well, do not seem to be supported in github for mac. Perhaps I have simply not found them in the interface yet.
In terms of workflow, performing tasks in github for mac is more cumbersome. The gui, while nice, does not fit all that well to a fast git workflow. You must wait for panes to load separately from one another, so one code review and commit may involve loading several panes. This is much different from Tower, which tends to keep most tasks present in the main window. In a dual-monitor setup, Tower works well when occupying a screen, while github for mac would be wasting space if used in that format.
The history browser, too, is quite simplistic. Tower can render commit history in the way that github for mac has chosen to do it, but I prefer the way that gity and others have allowed a history list and commit tree. One thing I like about Tower is the ability to scroll down a commit history and instantly see the diffs of that commit. With github for mac, you must click on a commit and bring up the diff in the whole window -- which seems a symptom of its non-multitasking workflow.
At this point, I could not see myself using this over Tower in any project scope, though this is of course tinged by my experience with working with Tower. It is very nice that github for mac is free, and having more offerings in the space is going to be great for innovation, but I do wish they had taken a different approach with their interface. Perhaps more to like will come of further use.
I've been using Tower for a few months, GitHub.app for a few minutes. Tower makes a lot of sense if you understand how Git works--it uses the same vocabulary (branches, remotes, fetc/push/pull, etc.) and encourages the same workflow.
GitHub.app seems like it's trying to take some of the complexity out of Git for beginners. For example, I'm looking at the "Changes" tab and don't see a distinction between staged and local changes. There's just a "Sync Branch" at the top that presumably does a pull, you don't get to have multiple remotes, just a "primary remote repository". No --rebase on pull, either.
Basically it looks to me like GitHub.app is trying to make common scenarios a lot easier to understand, but you have to go elsewhere for anything even slightly outside the lines. Could be the right tool for getting Git newbies (or even VCS newbies) onto the Git/GitHub wagon, especially for those who don't aspire to ever be Git experts. But heavy Git users, I'm guessing, will not be tempted.
I used Tower for a while, and I didn't have the chance to test Git for Mac yet (will do later today when I'll be using my Mac).
One thing that Tower can do quite well is dealing with multiple remote repositories (e.g. github + heroku).
If GitHub for Mac does that as well, I believe I'm going to switch to that.
Correction: It only works with a single 'origin' remote. It should work fine with any smart http git host. Someone in this thread mentioned it working just fine with Assembla.
I'm still not getting the Unique Selling Point. Or is this just a case of the intersection of Github fanboys and Mac fanboys? Once both of those factors are removed, I'm not seeing the magic.
It's a good first attempt, but it's not quite there yet and won't replace gitbox in my workflow.
The big problem is that it will only work with the origin remote [1]. This means no pulling in upstream changes, then pushing it to your fork - doing this on multiple branches with the command line is a pain, and something a GUI would be great for.
The interface feels a little half baked too, e.g why the multiple overlapping sidebars - one blue, one black, why not just merge them?
This is a huge deal. The app looks amazing. I used Tower for a bit but didn't cut it for me. I was planning to ditch Github for Codebase tonight but I'll reconsider after this
That's kind of like saying that a BMW M5 is just a version of a Ford Fiesta. Both will get you there, but the comfort and enjoyment will be somewhat different.
You're right. I'm not that good at metaphors and that one doesn't do the web app justice. My point was that while the two solutions are more or less functionally equivalent, they do differ significantly in ease-of-use and overall comfort.
I'm very, very happy that GitHub is doing this — but I also have high expectations and I do expect the app to improve significantly.
This is huge, because for many people, the current interface to git is the command line, which is too much for people who want GUIs. Yes, there are other GUIs out there, but those are not controlled by GitHub. In this case, they did something very similar to what Google did with Chrome; they wanted to provide a consistent and predictable end-to-end solution for users so they built their own desktop app.
It also does not hurt that the app defaults to use GitHub, though it does seem like you can use remotes that are not GitHub (see repository -> Settings).
Looks great! One more reason for developers to move over to Git and a great way to get more people on GitHub.
On another note, I wonder if this is another example of how native applications are gaining momentum on the desktop as a carry-over from the mobile apps industry. Perhaps, more companies will begin asking the question "if native apps beat web apps on mobile devices, why not on the desktop as well?"
Looks nice. For someone who has some decent familiarity with version control but none with git specifically: does anybody have any opinion on whether this would be a good way to pick up git for use with Xcode? Version control has always struck me as lending itself well to visual tools so I'm always kind of surprised how poor they usually tend to be.
Though Xcode 4 does support git, I've stuck with using git from the command line mostly, as I'd had some issues with it in Xcode 4 (betas, mind you). My guess is it's a lot more stable now.
Having said that, I still use it from the command line just fine. And you're right, it's often the case where a version control tool like git requires something more visual (especially when dealing with out-of-sync branch merging). For that I've typically used GitX, but GitHub for Mac so far looks like a really nice alternative.
Why have multiple accounts? The idea is that you have Organizations for business stuff, and you just switch "contexts" between personal and organizations.
This is not going to save anyone any time over the cli, only make it easier for people who are scared of it. When I'm writing, I hate going to the mouse when I don't have to. Give me a GUI where I can still use my keyboard and I'd pay a hundred bux for that shit.
It looks really nice, but I don't see myself switching from command-line Git (except for maybe when viewing logs and/or diffs). This will definitely be awesome for working with designers though.
Hot damn! This is a sweet app. I've been trying to get into github but I do not like the command line. This is a sweet app and should get many n00bs like me into github.
It's crashing quite a bit with me - all I do is to fire it up via /usr/local/bin/github while inside a repo. It displays the changes, but more often than not it crashes...
Looks pretty good. Why doesn't it respect .gitignore files though? I opened a C++ project and it wanted to commit about thirty object files, and things like that...
Well, for one thing, they both have very pretty UIs that are severely dysfunctional in exactly the same way: you can only have one window open at a time, which means you can't use the app to look at two repos at the same time.
For seriously using git for development, I find that pretty nuts.
Every time I want to browse a different repository, I have to destroy all the work I did opening the window for the current repo and drilling down through the UI to get to the part I am interested in? Seems crazy.
I think more apps would do well to learn from the windowing strategy of Mail.app on Mac. It too has a monolithic main window where everything happens--but Cmd-Opt-N creates a "New Viewer Window". Another complete window with all the power of the first. Search for foo in window 1, read mail list bar in window 2.
This sort of arrangement would make Github for Mac (and Tower) worth looking at.
As it is, if I have to throw away several seconds of work everysingletimeIopenanotherrepo, those seconds are going to add up -- and annoy me -- very quickly.
(By the way, just to check, I tried out making a few copies of the app and opening multiple repos that way. Just like Tower, the app started to puke modal error dialogs and show blank windows, so that doesn't work.)
I think you mean "Is it reasonable to be disappointed this doesn't support 10.4", in which case no, I don't think it's reasonable. 10.4 stopped being updated in Nov '07.
I'm sorry, but in the world of awesomely-licensed Qt and other cross-platform toolkits, why would you go out of your way to build a native app on Mac libraries and only release it for a single platform?
I can understand that OS X probably has the biggest share of GitHub visitors, but git is fully open source, GitHub seem to very much like open source, and in the spirit of that I'd expect a native app that works on as many platforms as possible.
a native app that works on as many platforms as possible
The definition of native app has changed. It's no longer a synonym for compiled binary; or using native widget. It is not as simple as coding your UI in a cross-platform toolkit. In these days, a native app means something that feels like the built-in apps: it's beyond skinning and appearance and is more about how the app as a whole interacts with the user to get the job done. As the platforms diverge, it's now really hard - if not impossible - to make a cross-platform native app. Among Performance, Cost, Time, Scope, you can only pick three. GitHub sacrifices the scope.
Reminds me of when Intuit was building out Quicken -- most of their versions were built using cross platform tools, but inside the code it became a big mess and most recently they decided to scrap the whole thing and re-write the mac client in native objective-c instead of c++
Sure you can build cross-platform stuff using Java or QT, but has anyone actually liked the stuff that came out from that?
Syntevo products (SmartSVN, SmartGit, SmartSynchronize) are actually bearable. I started using SmartSVN back when I used to use three platforms for desktop (Win, Linux, Mac) interchangeably and continued using it for subversion after moving to Mac.
Won't see myself using SmartGit though (we are moving to git). Will stick to command line with occasional launch of GitX or other native client.
Since you're new here I'll just give you an FYI. This kind of comment is going to get you downvotes because it doesn't add anything tangible to the discussion. We value a really high signal to noise ratio.
Some feedback:
* Get rid of huge spacing everywhere (for example here: http://github-images.s3.amazonaws.com/blog/2011/mac-screensh...)
* Make animations go faster.
* History should have preview pane with diffs (see Mail) instead of making me click on commits.
* There are windows on Macs. You can use them instead of [edit: or in addition to] making me navigate inside a single window.
* Loading indicators are annoying. Move them to bottom (there it won't distract me, but I'll know that it's still loading).
Oh, and congrats on release.