I’m periodically re-trying GitHub’s GUI client, just in case it becomes stable enough for anyone to use on a real project.
Today, with the latest version: every time I start the app, it immediately hard-crashes. The app is literally unusable – it won’t run at all.
At least with the previous versions it would actually start up, so … this is a pretty big step backwards. If it had decent error reporting, like most apps do, I might be able to work out what’s wrong, but of course that’s one of the original problems with GitHub’s app – it disables all error reporting.
(as an aside: it’s interesting that Apple’s Mac App Store has made it so rare to see an app crash that … I can’t even be bothered to try and fix this app or complain about it. For an app to crash on startup is so VERY far behind the current “normal” for apps that … it’s just not worth the effort. I think the Mac App Store is one of the worst things to happen to computing in the last 20 years [if the US govt allows Apple and Microsoft to continue in this way, computers will become a thing of the past], but I have to admit it is achieving some great things)
2 replies on “GitHub 2nd chance: infinite crashes”
This is a fascinating program, if only for the range of bugs it demonstrates. I’ve had four showstoppers, usually of the “won’t sync, don’t know why” sort, one of which you described in a previous post. The “we can do better [error reporting]” log message has been suppressed or removed, by the way, although the error reporting problem persists, as you pointed out.
Here’s another data point: as I write this, the GitHub app icon is bouncing in my dock for the fourth time, alerting me of a non-existent conflict using a popup that disappears with a nice roll-up animation as soon as I bring the app to the foreground. I have the latest version, yet this bug was supposedly fixed in April.
Giving the developers the benefit of the doubt, it looks like they are trying to introduce a less-Git conceptual model over a Git library, and they’re having a rough time of it. I sympathize, but I can’t afford the time or risk of catastrophic loss that goes with debugging a source control application.
Perhaps my fears are overblown, but if a program doesn’t behave in a reasonably reliable way, can it be counted upon to handle a bogus conflict without doing something unreasonable? My opinion is that it can’t, so when I give it another dry run, I won’t use it on any computer with uncommitted code changes, which is pretty counterproductive for an SCM tool.
I suppose it could still use my credentials to nuke my remote repository, but that would require a successful network operation. That said, I just got a message “could not delete the branch. It was probably already deleted” clicking the publish button on the branches tab, so who knows.
Given the importance of trust to GitHub’s business model, I’m surprised that they continue to distribute this. At the very least, it needs incubation and QA.
LOL @ “could not delete branch” when trying to Publish