21 comments

[ 3.1 ms ] story [ 54.0 ms ] thread
I'd like to see Versions http://www.versionsapp.com/ for Git.
I'd like to see Cornerstone http://www.zennaware.com/ for Git. :)
Touché, that app looks amazing.
Man I can never believe single developers can churn out such well-designed apps of this magnitude.

edit: Gorgeous logo too!

Dammit, now I do too! I almost want to buy that app and I don't even use Subversion...
Slick though both Versions and Cornerstone look, neither of them support svn merging. Does anyone know of a GUI subversion client on Mac that does?
GitX is just awesome, and getting better every day. You can currently stage and commit changes using the app, among other things (check out the 'committing' and 'advanced' screencasts on http://gitx.frim.nl/seeit.html).

Best of all: it's open source and makes great use of HTML & JavaScript. Even if you don't know ObjC, you can contribute.

http://gitabulous.com/ is supposed to be nice and sexy.

I've asked to be reminded but I've heard nothing so far.

there was a lack of interest in this and the open source gitx proved to be hard to compete against.
I love GitX. While I'm developing I leave it up alongside Eclipse, and I actually like having a separate interface to my source control outside the IDE.
Does it have problems with large repositories? It seemed to hang, and when I tried restarting it it just crashed.
What do you need a GUI for?
I think that about Subversion, which is really just a versioned filesystem; the git command line is pretty complicated though.
I don't know if the versioned filesystem metaphor fits Subversion that well -- clients do not store history after all. It is usually what Git evangelists praise about their software; you can use Git as a simple versioned file system if you wish (git add/commit/log and you're all set).
Subversion is literally a filesystem; that is all it is. Most of Subversion's problems come from the fact that the metaphor doesn't fit the task very well.

The fact that Git clients store full histories is one of the things that makes it less like a filesystem; it is, instead, a system for managing overlapping patch streams.

Check out the core svn C APIs (nb: our product is built on them); it's basically an open/close/read/write/readdir system with one additional "history" option (which history snapshots an entire filesystem, not just individual files (like CVS) or patches (like git).

in many cases with a large project it's faster to work with a GUI. You can navigate complex hierarchies more quickly.
I am trying out Git for a new project and I think we are going to end up going back to SVN.

Problems:

There is no support user based auth, so you have to set up SSH keys. Pain for our non-techies in the group. You should be able to add users and get access via user/pw/repo url.

Bigger problem is the lack of Windows support. We have 2 people (the non-techies) on Windows and expecting them to learn the command line stuff isn't realistic.

If I could, I'd like to suggest using Mercurial instead. It is vastly better supported on Windows, has a simpler workflow, and allows HTTP-based authentication--no SSH keys required. Plus, if you really need git-like flexibility--rebasing and whatnot--it's there in the form of Mercurial patch queues.