7 ms·

Gitbox 1.0 released: a version control app for Mac

146 points by oleganza 16y ago

dabeeeenster 16y ago
65 MB? For a git browser? Really?
- DamonOehlman 16y ago
  Well it looks pretty. Pretty doesn't come cheap ya know ;)
- AllTom 16y ago
  I don't know why it takes that much space, but that doesn't seem like enough space to worry about on a Mac.
  - AllTom 16y ago
    Some of the applications on my computer that are bigger than Gitbox: Google Chrome, Wireshark, Inkscape, iPhoto, Komodo Edit, etc. My hard drive barely noticed when I downloaded Gitbox, so practically the only difference was a few extra seconds of download time that I didn't notice, that's all I was trying to say. Your comment was helpful to the developer in the end, so kudos.
- oleganza 16y ago
  First, it is not a browser. You actually do commits, merges and manipulate branches. The size is that big because Gitbox is bundled with official Git binaries so you don't have to install anything else. I will see how to bring the size down in the next versions. Anyway, this fact does not affect the performance and does not eat much memory.
  - to 16y ago
    so is that better than gitx?
    - oleganza 16y ago
      Gitbox is better because it is a pleasure to use. There are tons of little details which matter in a daily work. For instance, when you switch a branch and try to commit to it, the branch name will be highlighted to remind you that the branch was switched since last commit. If you forgot to switch back, you just cancel the prompt. This little thing instantly eliminates 50% of use cases for "git reset --hard" or "git cherry pick" and makes you happier. Also, Gitbox fetches remote commits automatically so see that you have to pull something: this eliminates unnecessary merge commits.
      - mxcl 16y ago
        I'll be sure to give it a thorough testing. Thanks for your work.
  - dabeeeenster 16y ago
    Thanks for the reply - I'm always suspicious of large binaries with OSX!
  - pornel 16y ago
    git-osx-installer package takes 4.3MB, but your git.bundle takes 150MB. The problem is that the bundle contains exactly same binary 104 times (git, git-add, git-apply, etc. are identical files, 1.3MB each). These should be symlinks. It might be ZIP's fault (doesn't support symlinks AFAIK). I distribute my apps as tar.bz2, and nobody complained yet.
    - dchest 16y ago
      ZIP on OS X supports symlinks.
      - oleganza 16y ago
        I couldn't get it store hardlinks properly (using ditto). Do you know how to fix that?
        corprew 16y ago
        is there a reason you can't write a script to make the links rather than zipping it up?
        oleganza 16y ago
        corprew: the situation with hardlinks and the app size will improve over time. I just had a lot of more important things to do. (sorry, cannot reply to you directly: no reply link)
    - blasdel 16y ago
      Is he really shelling out for every git operation, or are those binaries just extra roughage for technical users?
danieldk 16y ago
No Github integration, and does not seem to provide much over GitX. At the very least, GitX does have an inline diff viewer when you browse revisions. In Gitbox you have to click a modified file, and then it will launch FileMerge. Too uncomfortable.
- to 16y ago
  agreed. i dont know why one would pay 40 bucks for an app that already exists for free.
  - oleganza 16y ago
    Gitbox is superior to what you have today. Very common things like commiting and checking the status and log are much faster and cleaner than in the command line or GitX. It is easier to extract a file from history, compare and manage the branches. You also pay for a level of attention to details in Gitbox, I explain it here: http://news.ycombinator.com/item?id=1944698 http://news.ycombinator.com/item?id=1944698
    - ardell 16y ago
      Talk with some web designers who have been looking for a decent gui tool for git. They don't want to learn to use command line and aren't happy with existing tool support. They are your market. Go to a local designer meetup group and sell your software to every one of them. Iterate on feedback, absolutely, but don't iterate on feedback of hackers, iterate on feedback of people who actually want your software and are in your target market. If you're dead-set on developers as your market, there are a ton of folks who still use svn with a gui because "no good git guis exist". These are the non-power-users of version control. You're not likely to find them here or on super-technical sites, but they do exist and there are many of them. The unfortunate part is that if you market to them you'll probably end up having to build an Eclipse plug-in.
      - oleganza 16y ago
        Thanks for the inspiration :-)
makeramen 16y ago
holy crap. this might actually get me to finally make the jump from hg to git.
joao 16y ago
There seems to be also another git client coming out this month: http://www.git-tower.com/ http://www.git-tower.com/ — Git Tower The UI seems a little bit more confusing, not something simple. I still use GitX.
- Rygu 16y ago
  I'm using the Git Tower beta and I have to say, it works like a charm. It does everything that GitX does, but provides a better UI for everything. The only thing I miss from GitX is the ability to discard changes per changed line/block. In Tower, it is possible to stage per changed block though. [edit] One thing that I forgot to mention is that the developers are very active and responsive, even though it's a closed source project. I made a few suggestions and got replies for each of them within a week. (Compared to Gitbox, Git Tower is built by a whole team of devs.)
nestlequ1k 16y ago
I've been trying hard to use GitBox for the last 2 month (beta version), but the lack of a quick view for commits makes me always revert back to GitX. With GitX, I can easily cycle through all the files and see a quick summary of what was changed. With GitBox, I have to double click on every single file to get the diff. Either that, or just blind commit files. Not good options. GitBox has the best push/pull functionality of any git client so far. But its crappy commit panel is really holds it back.
- oleganza 16y ago
  All points a valid and will be addressed in the upcoming versions.
  - nestlequ1k 16y ago
    Awesome. Thanks!
SandB0x 16y ago
The tagline seems quite negative: "Linus made Git for himself. Gitbox brings Git to everyone." Without Linus' free creation this app wouldn't exist at all.
- oleganza 16y ago
  It's not negative at all. It is a credit to Linus as a creator. Linus made a great tool and the command line UI is enough for him. Gitbox just makes his creation accessible to others and everybody wins.
  - Hoff 16y ago
    Please don't get defensive. Accept the feedback. Move on. And yes, whether it was intended or not, that statement can be inferred as a negative.
- JonnieCache 16y ago
  Linus did make git literally for himself, and by extension the kernel community. If you look at his quote about the name "Git," I think it portrays accurately the wry attitude of mock-antagonism linus feels around git: "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git." - https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software) https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software...
- mxcl 16y ago
  It's only negative if you want to read it that way.
fuxx0r 16y ago
so, iam on ppc, will you provide 10.5 in the future?
- oleganza 16y ago
  Unfortunately, no. Gitbox is designed on top of GCD and blocks which are available in 10.6 (which is Intel-only). The tradeoff is worth it: with GCD I was able to implement sophisticated control flow cleaner and faster, and fix a lot of bugs.
  - fuxx0r 16y ago
    i see =/ well, ppc is drifting slowly out. but iam looking forward to buy a intel mac in the future, hopefully your application is still maintained =)
timc3 16y ago
Sorry, but that just looks confusing. Easy to stick with the shell tools.
itsnotvalid 16y ago
Command line version suits me well. If I need xcode integration, I can use xcode 4 preview, which has merging tools and code comparison boiled in. By the way the site talks about a discount until Dec 1, I guess I'd skip that discount no matter what, as others mentioned a tool called Git Tower which seems to have a pleaser UI. Some sites also suggested another open sourced Git UI called Gity http://gngrwzrd.com/ http://gngrwzrd.com/ other than GitX which to me is just another blend of git-gui. In the OSS part Gitnub (https://github.com/Caged/gitnub https://github.com/Caged/gitnub) is a UI for Github and Git in general, but this one is not pure Cocoa (requires RubyCocoa.
JonnieCache 16y ago
Obviously the command line version is going to suit most people here better. That is completely missing the point. This will be perfect for those of us who work in teams with less technical people who still need r/w access to repositories. This will save us from training the designer and manager types in our organisations to use the command line tools, and as such will pay for itself.
- AllTom 16y ago
  Developers, too. Until you study and play with git for a long time, local/remote branches and pushing/pulling are hard to understand and very hard visualize. With Gitbox it's like reading your e-mail. I promote it at work as "the git client with five buttons" because that simplicity is worth a lot.
js4all 16y ago
Git comes with a GUI tool. Run gitk to see commits, comments, history and diffs. I use it a lot and never needed another GUI tool. Anyway, great to see a new tool for devs who need more GUI support.
- masklinn 16y ago
  > Git comes with a GUI tool. Run gitk You're not an OSX user are you?
  - frou_dh 16y ago
    As in OS X users are less tolerant of badly designed GUIs?
    - mgkimsal 16y ago
      Not sure if this is what the OP was getting at, but typing 'gitk' in my OSX terminal nets me "segmentation fault" and has for some time.
    - masklinn 16y ago
      That might be a factor, but no, mainly as in "tk interfaces look and behave dreadfully on OSX, as do pretty much all X applications but even more so, when they accept to work at all". * Even from on a hot start, gitk takes almost 5s between invocation and startup (on a 2.4GHz MBP) where GitX takes roughly 2s on a cold start (cold-start gitk takes on the order of 10s). * X applications don't behave in OSX: Divvy's resizing doesn't work, shortcuts don't work well, the menus are all broken (and the "OSX Menu" is that of the X11 application rather than the application's own), etc… * X applications look horrible, even if you discount the clusterfuck that their interface might be, they redraw poorly and slowly, the areas "bounce" and the transitions tend to not "look right", and the whole widget set looks terribly out of place. Compare: Gitk http://imgur.com/9mtGu.png http://imgur.com/9mtGu.png, GitX http://imgur.com/xS2DI.png http://imgur.com/xS2DI.png gitk looks like I'm back in 1993.
      - 16y ago
frou_dh 16y ago
Well, everyone's talking about alternatives, but kudos for putting your own touch on the concept and launching your app. I'm going to try it.
veidr 16y ago
This is great. I hate maintaining a fork of gitx myself, and actually gitx is markedly inferior to a high-quality commercial Mac application. There just haven't been any of those for git yet. For Subversion, there are Versions and Cornerstone, which are really much more pleasant to use, but nowadays of course most of projects are using git. So I am stoked to see a promising developer take this on. I'm sure he will make a run at adding missing stuff like optional inline diff viewing and whatnot.
stevefink 16y ago
It's a good effort - although I agree with a lot of the folks commenting here, I cannot recommend this to anyone without Git experience over GitX. The good news is, there is plenty of room for an intuitive GUI based Git app, particularly with GitHub integration. It's frustrating working with non-developer types who need access to static assets that need to be versioned. I need to get them an SVN equivalent such as Cornerstone or Versions. Teaching them the command line and Git is an all too time consuming process and I have no choice but to ensure they know at least the basics on smaller projects where non-developers are tightly coupled with things like HTML/images, etc.
flipgimble 16y ago
Can anyone compare this to SourceTree? http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/ which appears to support git and mercurial as a native MacOSX app and only 8MB download. Both appear to be too early of a release for me to shell out $40 for.
- jonnii 16y ago
  I was going to post about sourcetree. I downloaded the trial, it's pretty good. It's written by the author of ogre3d. You should check it out.
- oleganza 16y ago
  Thanks for sharing the link. I have commented earlier on SmartGit, the same ideas apply to SourceTree as well. PS. The size is almost a non-issue since it does not affect performance and you don't download the app every day. Anyway, the size will go down in the next updates.
bobx11 16y ago
i recently downloaded a big pile of them... gitx (the development build) is by far the most feature rich one that I tried
idan 16y ago
While it's nice to see native Git apps taking off like this, I don't think this app is mature enough for daily use yet. Having to leave the app for a diff is too much of an interruption. I like that the author is paying attention to little details, and I'm sure he'll improve the app over time, but right now I'm not seeing $40 worth of value over GitX.
jomama 16y ago
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 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.

146 points by oleganza 16y ago

dabeeeenster 16y ago

65 MB? For a git browser? Really?

DamonOehlman 16y ago
Well it looks pretty. Pretty doesn't come cheap ya know ;)
AllTom 16y ago
I don't know why it takes that much space, but that doesn't seem like enough space to worry about on a Mac.
- AllTom 16y ago
  Some of the applications on my computer that are bigger than Gitbox: Google Chrome, Wireshark, Inkscape, iPhoto, Komodo Edit, etc. My hard drive barely noticed when I downloaded Gitbox, so practically the only difference was a few extra seconds of download time that I didn't notice, that's all I was trying to say. Your comment was helpful to the developer in the end, so kudos.
oleganza 16y ago
First, it is not a browser. You actually do commits, merges and manipulate branches. The size is that big because Gitbox is bundled with official Git binaries so you don't have to install anything else. I will see how to bring the size down in the next versions. Anyway, this fact does not affect the performance and does not eat much memory.
- to 16y ago
  so is that better than gitx?
  - oleganza 16y ago
    Gitbox is better because it is a pleasure to use. There are tons of little details which matter in a daily work. For instance, when you switch a branch and try to commit to it, the branch name will be highlighted to remind you that the branch was switched since last commit. If you forgot to switch back, you just cancel the prompt. This little thing instantly eliminates 50% of use cases for "git reset --hard" or "git cherry pick" and makes you happier. Also, Gitbox fetches remote commits automatically so see that you have to pull something: this eliminates unnecessary merge commits.
    - mxcl 16y ago
      I'll be sure to give it a thorough testing. Thanks for your work.
- dabeeeenster 16y ago
  Thanks for the reply - I'm always suspicious of large binaries with OSX!
- pornel 16y ago
  git-osx-installer package takes 4.3MB, but your git.bundle takes 150MB. The problem is that the bundle contains exactly same binary 104 times (git, git-add, git-apply, etc. are identical files, 1.3MB each). These should be symlinks. It might be ZIP's fault (doesn't support symlinks AFAIK). I distribute my apps as tar.bz2, and nobody complained yet.
  - dchest 16y ago
    ZIP on OS X supports symlinks.
    - oleganza 16y ago
      I couldn't get it store hardlinks properly (using ditto). Do you know how to fix that?
      - corprew 16y ago
        is there a reason you can't write a script to make the links rather than zipping it up?
      - oleganza 16y ago
        corprew: the situation with hardlinks and the app size will improve over time. I just had a lot of more important things to do. (sorry, cannot reply to you directly: no reply link)
  - blasdel 16y ago
    Is he really shelling out for every git operation, or are those binaries just extra roughage for technical users?

danieldk 16y ago

No Github integration, and does not seem to provide much over GitX. At the very least, GitX does have an inline diff viewer when you browse revisions. In Gitbox you have to click a modified file, and then it will launch FileMerge. Too uncomfortable.

to 16y ago
agreed. i dont know why one would pay 40 bucks for an app that already exists for free.
- oleganza 16y ago
  Gitbox is superior to what you have today. Very common things like commiting and checking the status and log are much faster and cleaner than in the command line or GitX. It is easier to extract a file from history, compare and manage the branches. You also pay for a level of attention to details in Gitbox, I explain it here: http://news.ycombinator.com/item?id=1944698 http://news.ycombinator.com/item?id=1944698
  - ardell 16y ago
    Talk with some web designers who have been looking for a decent gui tool for git. They don't want to learn to use command line and aren't happy with existing tool support. They are your market. Go to a local designer meetup group and sell your software to every one of them. Iterate on feedback, absolutely, but don't iterate on feedback of hackers, iterate on feedback of people who actually want your software and are in your target market. If you're dead-set on developers as your market, there are a ton of folks who still use svn with a gui because "no good git guis exist". These are the non-power-users of version control. You're not likely to find them here or on super-technical sites, but they do exist and there are many of them. The unfortunate part is that if you market to them you'll probably end up having to build an Eclipse plug-in.
    - oleganza 16y ago
      Thanks for the inspiration :-)

makeramen 16y ago

holy crap. this might actually get me to finally make the jump from hg to git.

joao 16y ago

There seems to be also another git client coming out this month: http://www.git-tower.com/ http://www.git-tower.com/ — Git Tower The UI seems a little bit more confusing, not something simple. I still use GitX.

Rygu 16y ago
I'm using the Git Tower beta and I have to say, it works like a charm. It does everything that GitX does, but provides a better UI for everything. The only thing I miss from GitX is the ability to discard changes per changed line/block. In Tower, it is possible to stage per changed block though. [edit] One thing that I forgot to mention is that the developers are very active and responsive, even though it's a closed source project. I made a few suggestions and got replies for each of them within a week. (Compared to Gitbox, Git Tower is built by a whole team of devs.)

nestlequ1k 16y ago

I've been trying hard to use GitBox for the last 2 month (beta version), but the lack of a quick view for commits makes me always revert back to GitX. With GitX, I can easily cycle through all the files and see a quick summary of what was changed. With GitBox, I have to double click on every single file to get the diff. Either that, or just blind commit files. Not good options. GitBox has the best push/pull functionality of any git client so far. But its crappy commit panel is really holds it back.

oleganza 16y ago
All points a valid and will be addressed in the upcoming versions.
- nestlequ1k 16y ago
  Awesome. Thanks!

SandB0x 16y ago

The tagline seems quite negative: "Linus made Git for himself. Gitbox brings Git to everyone." Without Linus' free creation this app wouldn't exist at all.

oleganza 16y ago
It's not negative at all. It is a credit to Linus as a creator. Linus made a great tool and the command line UI is enough for him. Gitbox just makes his creation accessible to others and everybody wins.
- Hoff 16y ago
  Please don't get defensive. Accept the feedback. Move on. And yes, whether it was intended or not, that statement can be inferred as a negative.
JonnieCache 16y ago
Linus did make git literally for himself, and by extension the kernel community. If you look at his quote about the name "Git," I think it portrays accurately the wry attitude of mock-antagonism linus feels around git: "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git." - https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software) https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software...
mxcl 16y ago
It's only negative if you want to read it that way.

fuxx0r 16y ago

so, iam on ppc, will you provide 10.5 in the future?

oleganza 16y ago
Unfortunately, no. Gitbox is designed on top of GCD and blocks which are available in 10.6 (which is Intel-only). The tradeoff is worth it: with GCD I was able to implement sophisticated control flow cleaner and faster, and fix a lot of bugs.
- fuxx0r 16y ago
  i see =/ well, ppc is drifting slowly out. but iam looking forward to buy a intel mac in the future, hopefully your application is still maintained =)

timc3 16y ago

Sorry, but that just looks confusing. Easy to stick with the shell tools.

itsnotvalid 16y ago

Command line version suits me well. If I need xcode integration, I can use xcode 4 preview, which has merging tools and code comparison boiled in. By the way the site talks about a discount until Dec 1, I guess I'd skip that discount no matter what, as others mentioned a tool called Git Tower which seems to have a pleaser UI. Some sites also suggested another open sourced Git UI called Gity http://gngrwzrd.com/ http://gngrwzrd.com/ other than GitX which to me is just another blend of git-gui. In the OSS part Gitnub (https://github.com/Caged/gitnub https://github.com/Caged/gitnub) is a UI for Github and Git in general, but this one is not pure Cocoa (requires RubyCocoa.

JonnieCache 16y ago

Obviously the command line version is going to suit most people here better. That is completely missing the point. This will be perfect for those of us who work in teams with less technical people who still need r/w access to repositories. This will save us from training the designer and manager types in our organisations to use the command line tools, and as such will pay for itself.

AllTom 16y ago
Developers, too. Until you study and play with git for a long time, local/remote branches and pushing/pulling are hard to understand and very hard visualize. With Gitbox it's like reading your e-mail. I promote it at work as "the git client with five buttons" because that simplicity is worth a lot.

js4all 16y ago

Git comes with a GUI tool. Run gitk to see commits, comments, history and diffs. I use it a lot and never needed another GUI tool. Anyway, great to see a new tool for devs who need more GUI support.

masklinn 16y ago
> Git comes with a GUI tool. Run gitk You're not an OSX user are you?
- frou_dh 16y ago
  As in OS X users are less tolerant of badly designed GUIs?
  - mgkimsal 16y ago
    Not sure if this is what the OP was getting at, but typing 'gitk' in my OSX terminal nets me "segmentation fault" and has for some time.
  - masklinn 16y ago
    That might be a factor, but no, mainly as in "tk interfaces look and behave dreadfully on OSX, as do pretty much all X applications but even more so, when they accept to work at all". * Even from on a hot start, gitk takes almost 5s between invocation and startup (on a 2.4GHz MBP) where GitX takes roughly 2s on a cold start (cold-start gitk takes on the order of 10s). * X applications don't behave in OSX: Divvy's resizing doesn't work, shortcuts don't work well, the menus are all broken (and the "OSX Menu" is that of the X11 application rather than the application's own), etc… * X applications look horrible, even if you discount the clusterfuck that their interface might be, they redraw poorly and slowly, the areas "bounce" and the transitions tend to not "look right", and the whole widget set looks terribly out of place. Compare: Gitk http://imgur.com/9mtGu.png http://imgur.com/9mtGu.png, GitX http://imgur.com/xS2DI.png http://imgur.com/xS2DI.png gitk looks like I'm back in 1993.
    - 16y ago

frou_dh 16y ago

Well, everyone's talking about alternatives, but kudos for putting your own touch on the concept and launching your app. I'm going to try it.

veidr 16y ago

This is great. I hate maintaining a fork of gitx myself, and actually gitx is markedly inferior to a high-quality commercial Mac application. There just haven't been any of those for git yet. For Subversion, there are Versions and Cornerstone, which are really much more pleasant to use, but nowadays of course most of projects are using git. So I am stoked to see a promising developer take this on. I'm sure he will make a run at adding missing stuff like optional inline diff viewing and whatnot.

stevefink 16y ago

It's a good effort - although I agree with a lot of the folks commenting here, I cannot recommend this to anyone without Git experience over GitX. The good news is, there is plenty of room for an intuitive GUI based Git app, particularly with GitHub integration. It's frustrating working with non-developer types who need access to static assets that need to be versioned. I need to get them an SVN equivalent such as Cornerstone or Versions. Teaching them the command line and Git is an all too time consuming process and I have no choice but to ensure they know at least the basics on smaller projects where non-developers are tightly coupled with things like HTML/images, etc.

flipgimble 16y ago

Can anyone compare this to SourceTree? http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/ which appears to support git and mercurial as a native MacOSX app and only 8MB download. Both appear to be too early of a release for me to shell out $40 for.

jonnii 16y ago
I was going to post about sourcetree. I downloaded the trial, it's pretty good. It's written by the author of ogre3d. You should check it out.
oleganza 16y ago
Thanks for sharing the link. I have commented earlier on SmartGit, the same ideas apply to SourceTree as well. PS. The size is almost a non-issue since it does not affect performance and you don't download the app every day. Anyway, the size will go down in the next updates.

bobx11 16y ago

i recently downloaded a big pile of them... gitx (the development build) is by far the most feature rich one that I tried

idan 16y ago

While it's nice to see native Git apps taking off like this, I don't think this app is mature enough for daily use yet. Having to leave the app for a diff is too much of an interruption. I like that the author is paying attention to little details, and I'm sure he'll improve the app over time, but right now I'm not seeing $40 worth of value over GitX.

jomama 16y ago

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 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.