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
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.
This is the biggest obstacle to getting web developers moved over to Git at work. I am moving the team to task branches over the next few months, and the whole idea of branching/merging/pushing/pulling is proving difficult for them to internalize. They can handle basic branching and the svn model, but for Git to be successful in my organization, I'll need something like this.
I registered to encourage development of tools such as this and to give it a thorough run-through at work.
Absolutely right! One of the guys I was working with at my last contract was an old Java guy that loved Eclipse. We talked about moving from SVN to Git but he resisted because there was no good, proven, stable, active development GUI for Git in Eclipse. Build that plug-in and you can charge for it - guaranteed!
> "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."
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.
One thing I notice is that gitbox seems to have a persistent notion of which repositories it cares about. This will not work well with how I (and presumably many other folks) use git/hg/et al.
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?
I understand the limitations of the current sidebar design. This will be improved over time.
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.
The question is, are you going to be using your GUI in addition to or instead of the command line. GitX fits into my thinking as a supplement to the command line (I'd never create a repository or commit with it, I just look at the graph and changes), while Gitbox could be a replacement for using the command line on OS X... I just think it needs a graph like GitX (and every other git GUI tool) and it needs to act a little more like Versions.app, which gives the impression that it's not just a few simple tasks for repositories, but the all-in-one experience.
Soon Gitbox will indeed provide all-in-one experience, but it will still look like a little simple app. No way it will look like an IDE: people should spend their time inventing, drawing and coding, not managing versions.
>Very common things like commiting and checking the status and log are much faster and cleaner than in the command line...
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
You may use Cmd+tab and keyboard shortcuts in Gitbox as well. It is even faster than in Terminal and you don't have to type "git status" or "git log" (even with aliases)
