Great job. Simplifying git into an intuitive and usable UI is really challenging, and I think you're on the right track.
The toolbar is great. It's very clear what's going on, what branch you're on, where you're going to push to, and how to push to another branch. Collapsing branch checkout into the local branch popup menu works really well.
Collapsing history and local changes into one list kicks ass; probably my favorite feature/design decision. Fetching ahead of time and showing new commits to be merged, along with highlighting new commits to be pushed, is probably the best thing I've seen done in a version control client.
I'm not a fan of checkboxes for staging. I was bummed when Xcode 4 went this route with their new git integration. But I like that select files -> commit does exactly what you expect, staging selected files automatically. Cmd-return to commit is great.
Here's some constructive feedback on a few details:
- It's unclear how to add a repository. File -> Open works, but this interaction feels broken because it's not a document-based app. It's a one-window collection based app with a source list. So the copy should read File -> Add Repository. But this should also be accessible in the UI. I dig the simplicity of the UI, and that there's no bottom bar chrome (which is challenging to achieve), but in this case there really should be a [+] button for adding repositories. I can understand the choice to not go that route, but it's a standard UI convention for source list based apps, so users expect it and are confused what to do without it.
- A source list should never resize with the window. The source list should stay fixed while the content view resizes with the window. And in the case of an NSSplitView with three panes, one should probably resize while the others stay fixed; this isn't as much of a rule, but it feels better in the UI. I would resize the middle view (which is usually standard), because it's most likely that the user wants to read more of the commit messages, apposed to the changed file list. This behavior is pretty standard, and definitely expected with the source list, but you don't get it for free from Cocoa. You have to resize the views manually with an NSSplitViewDelegate method. I noticed a few apps hit the market recently that missed this UI detail, presumably because it's not clear how to do this. Here's a simple example for a two pane, source/content split view. http://pastie.org/1346451
- The changed file list is a pixel south when you're viewing local changes to commit. With AppKit controls like tables, outlines, split views, etc., you sometimes have to push them a pixel into their container views, because they draw their own borders and when you have one inside the other, you can end up with multiple pixel borders. Or it's just off.
- Keyboard support is supper important with this kind of app. This is more a feature request, but I expected the left and right arrow keys to navigate me from repository to history list to changed file list and back. This interaction would speed up workflow tremendously.
- There's no reason for the source list to be collapsible, especially because it zeros out the source selection and kills the content view, but the content of the changed file list persists. This feels broken. There are some NSOutlineViewDelegate methods to tweak this and get it to show up as a section header, iTunes style.
- Prefixing the repo name with the parent directory is an interesting design decision. To me it feels a little broken because the repos are reordered in a non-alphabetic way, respecting their parent folders instead of the repo's folder name. It works well when it's /company/project, but feels busted when it's /some-folder/project. If they're not listed alphabetic to the repository folder, they should probably be user reorder-able.
- The icon is under-polished, but I like the composition and style.
- The diff is the deal-breaker. If this app had a built-in diff, I would say it's one of the best version control clients I've seen, even at it's early stage and under polish, because the simplified interaction is really good. Add an inline diff as soon as possible.
I'm working with a team on a git client as well, and we've spent a considerable amount of time iterating interaction ideas, trying to find simplified was to expose the power and flexibility of git, and in places have come up with similar solutions. Honestly, it's hard. So mad props for making a three button git app. It's really impressive. Keep at it.
And don't listen to nay-sayers. Feedback is great, but all we can do is look for the useful parts of it, and not get pulled down by the rest. I've spent a fair amount of time looking into the potential user base of git clients, and it's a really wide spectrum. Hardcore cli advocates are sub-set.