8 ms·

Designing GitHub for Mac

360 points by rtomayko 15y ago

beck5 15y ago
Has anyone been using this client, is it worth using as far as GUI's go?
- waleedka 15y ago
  I was excited when I heard about it, but after 5 minutes I was disappointed. Don't get me wrong, it's very well designed. But it didn't add value for me. I use GitX and I find it more useful, and has a better UI.
- kneath 15y ago
  The good news is that it's free — try it out and figure out if you like it or not.
- pnathan 15y ago
  I've been using it. My prior experience has been with TortoiseHG. I think it's a very simplified view of source control and badly needs to be iterated to appeal to power users. That said, I'd recommend it for novices to source control.
- msbarnett 15y ago
  I think it's a great simple interface for, say, our designers who may need to interact with git but don't necessarily need or want to know more about it than absolutely necessary. For power users, look elsewhere.
- ghotli 15y ago
  I've been using it for about five days and I keep it open alongside textmate. I'm a CLI diehard but I do still find myself using it for things like switching branches and checking what's in a commit. It really does add value as far as that's concerned.
  - beck5 15y ago
    I think you need a terminal window open when using git really (unlike mercurial but lets not fight now). I do however like Tower
    - ghotli 15y ago
      I've had both open. They compliment each other.
- RyanMcGreal 15y ago
  I'm curious to hear from people who don't know - and don't want to learn - git on the command line. If this gets those uses checking their work into repositories, it will be a net win for version control.
- sunchild 15y ago
  I've been using it. I like it a lot, but I can't figure out how to "git add ." in it! I don't know why people are trashing this app. It's not exactly hard to use the command line if you don't like this app. Using a GUI on git is just a convenience, and probably most useful for new git users.
  - rchowe 15y ago
    What I think part of the problem people have with it is that it doesn't necessarily do what a seasoned git user would expect when syncing remote repositories, such as the fact that it pushes and pulls at the same time, and the pulls aren't normal pulls, they're rebase pulls.
tptacek 15y ago
What a f'ing fantastic article. Thank you so much for writing this. I spent a decent chunk of time last year building up a somewhat large Cocoa application (a telling synecdoche of how ambitious the app is: it integrates libevent with the Cocoa loop and involved writing a whole new evented Redis-backed HTTPS cache in ObjC). But unfortunately, I got to the UI part of this project ("UI part", heh) thinking "this is going to be so much easier than webdev, look at all these tools!, and that was a crushing disappointment; getting anything reasonable on the screen has been intensely painful, and is if anything much harder than CSS3+JQ is on modern web apps. I'm thrilled to hear that at least to some extent, it isn't just me, and making a good-looking Cocoa app (especially your first) is just very hard.
- daeken 15y ago
  I'm not a web guy by any stretch of the imagination, as you well know, but I find doing webdev really easy compared to any GUI library out there. If I can say "ok, this is only going to work in embedded Webkit/Chrome/whatever", I can whip up something that's pretty and functional in no time at all. When faced with the same task in GTK/Qt/Wx/whatever, I fail miserably. I've done a good bit of both, but I doubt I'll ever go back to making desktop apps -- I can always embed a webserver into whatever I'm building, and do the UI that way...
- pmjordan 15y ago
  I had the same experience with my first Cocoa Touch/UIKit project. The GUI stuff far eclipsed the rest of the app in terms of development effort, which I did not expect. This hadn't been the case with previous GUI stuff I'd done (Windows apps, game UIs and the web), and took me completely by surprise. The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content. Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists. In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-) My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.
peteysd 15y ago
I've been enjoying the app these last few days. Nice job! It's a great add-on to an already killer service. I'm quite happy to send the folks at Github some of my money each month, because they really earn it.
tolmasky 15y ago
Without going into whether I agree with his assertions on Cocoa, if it seemed so much easier to do with web technologies, why didn't he just do it with web technologies? Cocoa is probably the framework best suited for incorporating web views, and tons of apps do this: Mail.app, iTunes, Aperture, Colloquy, etc. etc. Use the right tool for the right job, if you have something that is going to have a lot of flow-based layout, then by all means use WebView. It's kind of like refusing to use an NSTextView, then complaining about having to lay out text yourself.
- nfarina 15y ago
  Completely agree. Cocoa is appropriate for creating minimalist, system-styled UI. Not for rich flow-based content rendering. See Versions.app: native where it makes sense (filesystem treeview), Webkit elsewhere (history browser).
RyanMcGreal 15y ago
> Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub. I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.
thelicx 15y ago
Super interesting article
cdcarter 15y ago
He makes great points about MacRuby. I started tooling around with it for an app a few months ago, and though it was a great interface, it didn't make working in Cocoa any easier, and I still had to learn a lot of weird technology choices in Cocoa. Though, I think the difficulty of making a complex GUI in Cocoa shines in the OS X world. It's a lot harder to make a working UI, so you want to get the design right the first time, so you don't have to go back and re-do.
- lrz 15y ago
  Well, MacRuby is a language on top of Objective-C. You can use Cocoa with it, but you should be able to use the Chameleon framework too, assuming it is GC-friendly (otherwise, adding GC support shouldn't be hard). His points don't make much sense to me.
sant0sk1 15y ago
Great article for sure, but I take issue with these bits: > Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons. It's my understanding that for a really long time there was no linkable library for interacting with Git. So unless these devs wanted to first write said library they were pretty much left with putting buttons on the CLI. You might say "Well they should have written one, then!" but that is quite a risky capital expense on a piece of software that could easily flop. GitHub did it (with Summer of Code's help), but they have umpteen uses of such a library even if nobody uses GitHub for Mac. > It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home. I dunno, I think GitX (especially its forks) does some pretty special things, including making it dead simple to stage/unstage/discard single lines of files.
- scott_s 15y ago
  His point was that the OS X applications he saw were just a thin layer over the CLI program - they provided no new abstractions. Whether the OS X application calls a library or calls the CLI program(s) is an implementation detail not relevant to his point.
- tsetse-fly 15y ago
  programming is hard, let's go shopping!
pohl 15y ago
There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element. This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look for Session 103 "Cocoa Autolayout".
jkkramer 15y ago
> Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local. What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.
- TylerE 15y ago
  What if there was something like a git deploy command? Basically, when you don't actually care about git functionality on the remote (production/staging) end, that would actually change the remote files. (Yes, I know it can be done with a hook, but that's more of a power user solution, and it's still extra work to setup)
gregschlom 15y ago
> Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password. This sounds like a wrong design decision. I wish nobody could log into my github account using anything but my SSH keys. This is also true of my AWS account: my ec2 instances are protected by SSH keypairs, but if anyone gets my AWS password, he has full control over everything. I'm not a security expert, but SSH keys feel way safer than passwords, especially with all those recents article showing how easy it can be to bruteforce passwords.
- umjames 15y ago
  I think their goal was to make GitHub (and by extension git itself) more accessible to people who code, but are not familiar/comfortable enough with command line Unix or SSH to generate SSH keypairs. There are a lot of these people. Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
  - kisielk 15y ago
    Couldn't the app use your username / password to connect to github the first time and then generate an SSH key pair which it would use from that point forward? That seems like the best compromise of security and easy of use to me.
    - mechanical_fish 15y ago
      Then the client would only work easily with Github. That would be very sad for those of us who deploy Git repos on other servers than Github. As it is, I'm pretty sure this is using standard HTTPS auth with Git, which is not that hard to support.
      - kenneth_reitz 15y ago
        The client works fine with other Git servers, and uses your standard SSH keys. "Death to the SSH key" applies only to GitHub interactions — getting a list of your repos, for example.
chrismealy 15y ago
Dear github: clicking "published" on a project deletes it from github. That was a surprise!
- kenneth_reitz 15y ago
  http://kreitz.co/1H092e0h3z3y1v190v3T http://kreitz.co/1H092e0h3z3y1v190v3T
PartyDawg 15y ago
It's amazing, I thought I would come here to learn things, but instead I am teaching. Branching projects is hard in XCode? Zip up the project files and back up the revision... in I don't know, a source code repository? LOL! None of the re-writing is required in Xcode for your app. Design the app, then make it in Xcode. If you have to make revisions to the design of your app, go back to designing it. Most of the code can be re-used, but clearly you haven't finished designing the app yet... Interesting take on the initial experience. But instead of casting about for blame, it might be better to ask why your processes are going wrong.
oscardelben 15y ago
On a related note, i've built a simple github browser for ipad that will never get approved on the AppStore due to paid accounts. If someone wants to play with it here's the link https://github.com/oscardelben/GithubBrowser https://github.com/oscardelben/GithubBrowser
- leviathan 15y ago
  You can still create an account and provide the Apple reviewers with credentials to try it. This is what we did for an iPad project that uses Facebook photos, we provided Apple with login credentials to a facebook account with lots of photos in it so that they can test it, and the app was approved from the first submission.
  - oscardelben 15y ago
    Tried that without success. Maybe it depends on the person examinating it. Btw it took them two months to reject the app so there must have been something going on.
atomical 15y ago
Smartgit is an awesome client for mac and I love the diffs view. Git is complicated so does a simple client help or hurt? I think that's up for debate and different users are going to have different requirements but for me I feel Smartgit is simplistic, useful, and functional where as I think of the Github client as more of an RSS type application where I check the latest stuff that has been committed.
natesm 15y ago
On the images/code drawing points: are there any benchmarks for this? I've been writing meticulous CGGradient type stuff recently, should I just make a gradient in Photoshop and call it a day instead?
- theatrus2 15y ago
  Depends on how you handle the gradients - CG has some neat tricks about reusing gradient rendering if you don't instantiate the same one over and over.
mmphosis 15y ago
Auto Save and Versions http://www.apple.com/macosx/whats-new/auto-save.html http://www.apple.com/macosx/whats-new/auto-save.html
- pornel 15y ago
  These APIs are not well-suited for git-like version control. They're document-oriented, rather than project oriented (or if you present git repository as bundle, you lose nifty per-document presentation). iCloud may force creation of versions (commits?) There's no branching. There's lots of locking and exclusive access.
swaits 15y ago
I use SourceTree. It's not free, it's definitely not cheap, but it's badass. http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/ (I have no affiliation, just a happy customer)
grimen 15y ago
I really like what GitHub do, though in this case I would say that the GitX client (forked one) is way more productive and overview:aböe IMO. I even managed to teach my MBA partner how to use it - this one is actually a bit more confusing than GitX interface. Abstraction is not always for the good, but a very good try at least.
ttrashh 15y ago
I'd love to see a good comparison from someone with a good bit of WPF/Silverlight/Xaml and Cocoa experience.
dolinsky 15y ago
Could someone elaborate on the difficulties encountered managing branches of an iOS project in XCode using git?
- deleted 15y ago
  [deleted]
- kneath 15y ago
  Xcode tracks files with an XML "project file." So if you add files in one branch and remove files in another branch, it often puts this project file into a conflicted state. Resolving conflicts in this file is really difficult — lots of confusing paths and SHAs all mixed together. If you don't resolve conflicts correctly, the entire project refuses to open.
  - dolinsky 15y ago
    Thanks, that makes sense. Is it often that these conflicts arise during development on a team of 1-3 developers? I'm also assuming you're referring to the package contents of the .xproj file (specifically project.pbxproj), correct?
- xsmasher 15y ago
  I work on a project with 3 other devs; an xcode conflict is an "oh, bummer" moment, but not a hairpuller. 90% of the time we've both added files, and the merge is as easy as "choose both." It's still the sort of thing where you want to check out, change the project, and check back in quick to avoid conflicts. I can imagine it getting worse with far-distance branches though. It's not too different from a makefile, except you'll get a better error message when you muck up your makefile.
rawsyntax 15y ago
The bit about the NDA is a little ridiculous. Apple wouldn't be able to politely ask people not to blog about their stuff.
cageface 15y ago
As an aside, I really feel like Apple is losing the plot with their latest batch of UIs. Wooden end panels, birch bookshelves, the glossy reflective dock, leather-bound notebooks etc, all smack of a lack of imagination and an timid need to convey value in outmoded terms.
- andrewf 15y ago
  It's called skeumorphism. You're not the only one. http://speedbird.wordpress.com/2010/06/25/what-apple-needs-to-do-now/ http://speedbird.wordpress.com/2010/06/25/what-apple-needs-t...
  - cageface 15y ago
    What are these but misguided coddles, patronizing crutches, interactively horseless carriages? Nailed it. Great article. Apple's hardware is as beautiful as ever but their software UI seems to have gone right of the rails. I wish Google's wasn't aping that dumb page curl effect in their own books app.
  - pittsburgh 15y ago
    Howard Roark (of Ayn Rand's Fountainhead) would hate where Apple is taking their design. From the book: "His buildings are austere, logical, perfect, each a single thought in stone. He believes that buildings, like men, have souls, and that no part of a building should in any way betray its soul. No building should borrow its parts from others or apologize for its own shape. No building should present a false front." And another quote: "The buildings in these drawings are like none ever built on earth. They seem severe and simple at ﬁrst glance, but closer observation reveals the strict tension of thought and method, a cold, beautiful logic behind each wall and pillar. Every building seems to have a soul." I hope Apple turns down the woodgrain knob and cranks up the cold, beautiful, and logical knob in their future designs.
vladocar 15y ago
This is so unfair. I finally mastered the GIT console pushing and pulling stuff around. And this awesome product comes and the console is now obsolete. Jokes apart, this is super tool that will bring new users that are still not familiar with the console. Great job guys!
dsp2138 15y ago
我是中国人
gawker 15y ago
Just wanted to say thank you so very much! I'm just getting started on trying to build an iOS/Mac application system and while it's fairly straightforward to build it, the design of the user interface is what gets me. Going from ok to 'wow' is what really sets Mac applications apart from most PC applications.

360 points by rtomayko 15y ago

beck5 15y ago

Has anyone been using this client, is it worth using as far as GUI's go?

waleedka 15y ago
I was excited when I heard about it, but after 5 minutes I was disappointed. Don't get me wrong, it's very well designed. But it didn't add value for me. I use GitX and I find it more useful, and has a better UI.
kneath 15y ago
The good news is that it's free — try it out and figure out if you like it or not.
pnathan 15y ago
I've been using it. My prior experience has been with TortoiseHG. I think it's a very simplified view of source control and badly needs to be iterated to appeal to power users. That said, I'd recommend it for novices to source control.
msbarnett 15y ago
I think it's a great simple interface for, say, our designers who may need to interact with git but don't necessarily need or want to know more about it than absolutely necessary. For power users, look elsewhere.
ghotli 15y ago
I've been using it for about five days and I keep it open alongside textmate. I'm a CLI diehard but I do still find myself using it for things like switching branches and checking what's in a commit. It really does add value as far as that's concerned.
- beck5 15y ago
  I think you need a terminal window open when using git really (unlike mercurial but lets not fight now). I do however like Tower
  - ghotli 15y ago
    I've had both open. They compliment each other.
RyanMcGreal 15y ago
I'm curious to hear from people who don't know - and don't want to learn - git on the command line. If this gets those uses checking their work into repositories, it will be a net win for version control.
sunchild 15y ago
I've been using it. I like it a lot, but I can't figure out how to "git add ." in it! I don't know why people are trashing this app. It's not exactly hard to use the command line if you don't like this app. Using a GUI on git is just a convenience, and probably most useful for new git users.
- rchowe 15y ago
  What I think part of the problem people have with it is that it doesn't necessarily do what a seasoned git user would expect when syncing remote repositories, such as the fact that it pushes and pulls at the same time, and the pulls aren't normal pulls, they're rebase pulls.

tptacek 15y ago

What a f'ing fantastic article. Thank you so much for writing this. I spent a decent chunk of time last year building up a somewhat large Cocoa application (a telling synecdoche of how ambitious the app is: it integrates libevent with the Cocoa loop and involved writing a whole new evented Redis-backed HTTPS cache in ObjC). But unfortunately, I got to the UI part of this project ("UI part", heh) thinking "this is going to be so much easier than webdev, look at all these tools!, and that was a crushing disappointment; getting anything reasonable on the screen has been intensely painful, and is if anything much harder than CSS3+JQ is on modern web apps. I'm thrilled to hear that at least to some extent, it isn't just me, and making a good-looking Cocoa app (especially your first) is just very hard.

daeken 15y ago
I'm not a web guy by any stretch of the imagination, as you well know, but I find doing webdev really easy compared to any GUI library out there. If I can say "ok, this is only going to work in embedded Webkit/Chrome/whatever", I can whip up something that's pretty and functional in no time at all. When faced with the same task in GTK/Qt/Wx/whatever, I fail miserably. I've done a good bit of both, but I doubt I'll ever go back to making desktop apps -- I can always embed a webserver into whatever I'm building, and do the UI that way...
pmjordan 15y ago
I had the same experience with my first Cocoa Touch/UIKit project. The GUI stuff far eclipsed the rest of the app in terms of development effort, which I did not expect. This hadn't been the case with previous GUI stuff I'd done (Windows apps, game UIs and the web), and took me completely by surprise. The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content. Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists. In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-) My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.

peteysd 15y ago

I've been enjoying the app these last few days. Nice job! It's a great add-on to an already killer service. I'm quite happy to send the folks at Github some of my money each month, because they really earn it.

tolmasky 15y ago

Without going into whether I agree with his assertions on Cocoa, if it seemed so much easier to do with web technologies, why didn't he just do it with web technologies? Cocoa is probably the framework best suited for incorporating web views, and tons of apps do this: Mail.app, iTunes, Aperture, Colloquy, etc. etc. Use the right tool for the right job, if you have something that is going to have a lot of flow-based layout, then by all means use WebView. It's kind of like refusing to use an NSTextView, then complaining about having to lay out text yourself.

nfarina 15y ago
Completely agree. Cocoa is appropriate for creating minimalist, system-styled UI. Not for rich flow-based content rendering. See Versions.app: native where it makes sense (filesystem treeview), Webkit elsewhere (history browser).

RyanMcGreal 15y ago

> Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub. I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.

thelicx 15y ago

Super interesting article

cdcarter 15y ago

He makes great points about MacRuby. I started tooling around with it for an app a few months ago, and though it was a great interface, it didn't make working in Cocoa any easier, and I still had to learn a lot of weird technology choices in Cocoa. Though, I think the difficulty of making a complex GUI in Cocoa shines in the OS X world. It's a lot harder to make a working UI, so you want to get the design right the first time, so you don't have to go back and re-do.

lrz 15y ago
Well, MacRuby is a language on top of Objective-C. You can use Cocoa with it, but you should be able to use the Chameleon framework too, assuming it is GC-friendly (otherwise, adding GC support shouldn't be hard). His points don't make much sense to me.

sant0sk1 15y ago

Great article for sure, but I take issue with these bits: > Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons. It's my understanding that for a really long time there was no linkable library for interacting with Git. So unless these devs wanted to first write said library they were pretty much left with putting buttons on the CLI. You might say "Well they should have written one, then!" but that is quite a risky capital expense on a piece of software that could easily flop. GitHub did it (with Summer of Code's help), but they have umpteen uses of such a library even if nobody uses GitHub for Mac. > It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home. I dunno, I think GitX (especially its forks) does some pretty special things, including making it dead simple to stage/unstage/discard single lines of files.

scott_s 15y ago
His point was that the OS X applications he saw were just a thin layer over the CLI program - they provided no new abstractions. Whether the OS X application calls a library or calls the CLI program(s) is an implementation detail not relevant to his point.
tsetse-fly 15y ago
programming is hard, let's go shopping!

pohl 15y ago

There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element. This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look for Session 103 "Cocoa Autolayout".

jkkramer 15y ago

> Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local. What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.

TylerE 15y ago
What if there was something like a git deploy command? Basically, when you don't actually care about git functionality on the remote (production/staging) end, that would actually change the remote files. (Yes, I know it can be done with a hook, but that's more of a power user solution, and it's still extra work to setup)

gregschlom 15y ago

> Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password. This sounds like a wrong design decision. I wish nobody could log into my github account using anything but my SSH keys. This is also true of my AWS account: my ec2 instances are protected by SSH keypairs, but if anyone gets my AWS password, he has full control over everything. I'm not a security expert, but SSH keys feel way safer than passwords, especially with all those recents article showing how easy it can be to bruteforce passwords.

umjames 15y ago
I think their goal was to make GitHub (and by extension git itself) more accessible to people who code, but are not familiar/comfortable enough with command line Unix or SSH to generate SSH keypairs. There are a lot of these people. Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
- kisielk 15y ago
  Couldn't the app use your username / password to connect to github the first time and then generate an SSH key pair which it would use from that point forward? That seems like the best compromise of security and easy of use to me.
  - mechanical_fish 15y ago
    Then the client would only work easily with Github. That would be very sad for those of us who deploy Git repos on other servers than Github. As it is, I'm pretty sure this is using standard HTTPS auth with Git, which is not that hard to support.
    - kenneth_reitz 15y ago
      The client works fine with other Git servers, and uses your standard SSH keys. "Death to the SSH key" applies only to GitHub interactions — getting a list of your repos, for example.

chrismealy 15y ago

Dear github: clicking "published" on a project deletes it from github. That was a surprise!

kenneth_reitz 15y ago
http://kreitz.co/1H092e0h3z3y1v190v3T http://kreitz.co/1H092e0h3z3y1v190v3T

PartyDawg 15y ago

It's amazing, I thought I would come here to learn things, but instead I am teaching. Branching projects is hard in XCode? Zip up the project files and back up the revision... in I don't know, a source code repository? LOL! None of the re-writing is required in Xcode for your app. Design the app, then make it in Xcode. If you have to make revisions to the design of your app, go back to designing it. Most of the code can be re-used, but clearly you haven't finished designing the app yet... Interesting take on the initial experience. But instead of casting about for blame, it might be better to ask why your processes are going wrong.

oscardelben 15y ago

On a related note, i've built a simple github browser for ipad that will never get approved on the AppStore due to paid accounts. If someone wants to play with it here's the link https://github.com/oscardelben/GithubBrowser https://github.com/oscardelben/GithubBrowser

leviathan 15y ago
You can still create an account and provide the Apple reviewers with credentials to try it. This is what we did for an iPad project that uses Facebook photos, we provided Apple with login credentials to a facebook account with lots of photos in it so that they can test it, and the app was approved from the first submission.
- oscardelben 15y ago
  Tried that without success. Maybe it depends on the person examinating it. Btw it took them two months to reject the app so there must have been something going on.

atomical 15y ago

Smartgit is an awesome client for mac and I love the diffs view. Git is complicated so does a simple client help or hurt? I think that's up for debate and different users are going to have different requirements but for me I feel Smartgit is simplistic, useful, and functional where as I think of the Github client as more of an RSS type application where I check the latest stuff that has been committed.

natesm 15y ago

On the images/code drawing points: are there any benchmarks for this? I've been writing meticulous CGGradient type stuff recently, should I just make a gradient in Photoshop and call it a day instead?

theatrus2 15y ago
Depends on how you handle the gradients - CG has some neat tricks about reusing gradient rendering if you don't instantiate the same one over and over.

mmphosis 15y ago

Auto Save and Versions http://www.apple.com/macosx/whats-new/auto-save.html http://www.apple.com/macosx/whats-new/auto-save.html

pornel 15y ago
These APIs are not well-suited for git-like version control. They're document-oriented, rather than project oriented (or if you present git repository as bundle, you lose nifty per-document presentation). iCloud may force creation of versions (commits?) There's no branching. There's lots of locking and exclusive access.

swaits 15y ago

I use SourceTree. It's not free, it's definitely not cheap, but it's badass. http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/ (I have no affiliation, just a happy customer)

grimen 15y ago

I really like what GitHub do, though in this case I would say that the GitX client (forked one) is way more productive and overview:aböe IMO. I even managed to teach my MBA partner how to use it - this one is actually a bit more confusing than GitX interface. Abstraction is not always for the good, but a very good try at least.

ttrashh 15y ago

I'd love to see a good comparison from someone with a good bit of WPF/Silverlight/Xaml and Cocoa experience.

dolinsky 15y ago

Could someone elaborate on the difficulties encountered managing branches of an iOS project in XCode using git?

deleted 15y ago
[deleted]
kneath 15y ago
Xcode tracks files with an XML "project file." So if you add files in one branch and remove files in another branch, it often puts this project file into a conflicted state. Resolving conflicts in this file is really difficult — lots of confusing paths and SHAs all mixed together. If you don't resolve conflicts correctly, the entire project refuses to open.
- dolinsky 15y ago
  Thanks, that makes sense. Is it often that these conflicts arise during development on a team of 1-3 developers? I'm also assuming you're referring to the package contents of the .xproj file (specifically project.pbxproj), correct?
xsmasher 15y ago
I work on a project with 3 other devs; an xcode conflict is an "oh, bummer" moment, but not a hairpuller. 90% of the time we've both added files, and the merge is as easy as "choose both." It's still the sort of thing where you want to check out, change the project, and check back in quick to avoid conflicts. I can imagine it getting worse with far-distance branches though. It's not too different from a makefile, except you'll get a better error message when you muck up your makefile.

rawsyntax 15y ago

The bit about the NDA is a little ridiculous. Apple wouldn't be able to politely ask people not to blog about their stuff.

cageface 15y ago

As an aside, I really feel like Apple is losing the plot with their latest batch of UIs. Wooden end panels, birch bookshelves, the glossy reflective dock, leather-bound notebooks etc, all smack of a lack of imagination and an timid need to convey value in outmoded terms.

andrewf 15y ago
It's called skeumorphism. You're not the only one. http://speedbird.wordpress.com/2010/06/25/what-apple-needs-to-do-now/ http://speedbird.wordpress.com/2010/06/25/what-apple-needs-t...
- cageface 15y ago
  What are these but misguided coddles, patronizing crutches, interactively horseless carriages? Nailed it. Great article. Apple's hardware is as beautiful as ever but their software UI seems to have gone right of the rails. I wish Google's wasn't aping that dumb page curl effect in their own books app.
- pittsburgh 15y ago
  Howard Roark (of Ayn Rand's Fountainhead) would hate where Apple is taking their design. From the book: "His buildings are austere, logical, perfect, each a single thought in stone. He believes that buildings, like men, have souls, and that no part of a building should in any way betray its soul. No building should borrow its parts from others or apologize for its own shape. No building should present a false front." And another quote: "The buildings in these drawings are like none ever built on earth. They seem severe and simple at ﬁrst glance, but closer observation reveals the strict tension of thought and method, a cold, beautiful logic behind each wall and pillar. Every building seems to have a soul." I hope Apple turns down the woodgrain knob and cranks up the cold, beautiful, and logical knob in their future designs.

vladocar 15y ago

This is so unfair. I finally mastered the GIT console pushing and pulling stuff around. And this awesome product comes and the console is now obsolete. Jokes apart, this is super tool that will bring new users that are still not familiar with the console. Great job guys!

dsp2138 15y ago

我是中国人

gawker 15y ago

Just wanted to say thank you so very much! I'm just getting started on trying to build an iOS/Mac application system and while it's fairly straightforward to build it, the design of the user interface is what gets me. Going from ok to 'wow' is what really sets Mac applications apart from most PC applications.