Gitbox 1.0 released: a version control app for Mac
gitboxapp.com
gitboxapp.com
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.
Look at all the unanswered questions in Google results for how to integrate Mercurial or Git into Coda.
This class of developer is looking for tools between Dreamweaver and curl -- arguably, most developers.
Turning your tool into a plugin or add-on to some existing editors would garner a lot of them, with those editors' sites serving as a marketing platform too.
I registered to encourage development of tools such as this and to give it a thorough run-through at work.
git st, git add ., git ci seem pretty quick to me. I set aliases for status to st and commit to ci, but tab completion work pretty well. I've been stepping away from GUIs lately when the command line is available. It's quicker for my hands to stay on the keyboard than it is to switch to the mouse and back
Agreed. Why would anyone want to stop working, grab the mouse and click on a menu, when the command-line interface for git works perfectly.
Namely, for every little project with writing (latex) or programming (in some language), I create a repo. Over the course of a given year, this means easily 50+ repos, some short lived, some that I use for quite a while. I do not want to be dealing with a sidepane of my repos unless i can toggle it to show just eg "my 10 most recent repos" or the like, which I don't think gitbox seems to presently offer that.
Also, I approve of the choice of having a 1 repo limit thing as the distinguisher between with and sans license.
another question is: how do you plan to distinguish yourself from smartgit, which is the current / only gui'd paid osx git app?
Regarding smartgit: it is simply not for the people I'm trying to work for. It looks and feels like another scary development tool you should have a commitment with. I'm okay to have such tools if it is worth it. In case of version control, the app should be a simple small appliance which does not grab a lot of your attention.
I can try to understand how Linus spends a lot of time with git merging all the patches for his projects. He really needs to care about version control and browsing all the tiny details. For the rest of us, we work with code, graphics, but not with merges and versions. We should spend more time in Xcode and Photoshop than in any version control app. Smartgit is for guys like Linus, Gitbox is for everyone else.
Maintaining a tool like this is basically unpleasant. You either need to be maintaining it for internal customers in a large company, or you need to sell it as a product - in other words, it's one of those products you really want to get paid for.
Maybe having a paid project will help keep this app actively developed.
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.
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.
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.
The UI seems a little bit more confusing, not something simple. I still use GitX.
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.)
"Linus made Git for himself. Gitbox brings Git to everyone."
Without Linus' free creation this app wouldn't exist at all.
And yes, whether it was intended or not, that statement can be inferred as a negative.
"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...
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/ other than GitX which to me is just another blend of git-gui. In the OSS part Gitnub (https://github.com/Caged/gitnub) is a UI for Github and Git in general, but this one is not pure Cocoa (requires RubyCocoa.
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.
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.
(sorry, cannot reply to you directly: no reply link)
Anyway, great to see a new tool for devs who need more GUI support.
You're not an OSX user are you?
* 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, GitX http://imgur.com/xS2DI.png gitk looks like I'm back in 1993.
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.
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.
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.
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.
1. In 1.1 File->Open menu is renamed to Open Repository. Add button will appear in a totally redesigned window layout in the next releases.
2. Source list resizing is fixed in 1.1
3. I have removed the standard headers from the changes list which fixes the problem. This view will be greatly improved later, though.
4. Yes, keyboard navigation is crucial. Now you can navigate between all the panes with arrow keys. Plus, jumping through the list of repos or commits is optimized.
5. Source list collapsing will be addressed later. 1.1 fixed the issue with persisted changes list when no repo is selected.
6. Repo organization will improve in one of the nearest releases.