There are several decent GUI's for git on the Mac side of things; Github has even released their own guy.
http://www.git-tower.com/ http://mac.github.com/ http://gitx.frim.nl/ Git tower can be quirky, but you get used to it and the quirks make sense. I haven't really heard much about mac github. And the last I've heard mixed about. But I agree with the previous responders lack of gui support is not a reason. On Sat, Aug 27, 2011 at 10:33 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > I use CVS and SVN directly from Eclipse and I know exactly where you are > > coming from. Currently this all runs transparently on all platforms and > many > > of the 'reasons' given for wanting to change are already supported by > > additional tools _in_ Eclipse. > > http://eclipse.org/egit/ > http://www.javaforge.com/project/HGE > http://wiki.bazaar.canonical.com/BzrEclipse > > using the vcs from your IDE, or outside(either via gui or command > line) is a personal preference, for example I had problems with the > SVN intergration in Eclipse, so I tend to use it outside of Eclipse. > At least before I ditched eclipse. > > > Up until recently DVCS systems did not have > > such will integrated support, and this was the cause of most of my own > > problems. > > this has nothing to do with DVCS, usually new tools lacks support from > the third parties at first. > > > Having machines running both Windows and Linux in parallel for > > testing purposes I certainly don't want to be having to think which > platform > > I am on and changing the help manual! > > you don't necessarily need to edit the code on the different > platforms, only build and run it, but having a platform independent > development environment is a good thing. > > > > > TortoiseHg provides an independent integrated GUI which I currently use > in > > parallel with Eclipse to support Hg and git via hggit, but it lacks some > of > > the nice features of the SVN integration. MercurialEclipse has made a lot > of > > progress in the last few months and is starting to mimic the SVN tools, > but > > still has a few rough edges. Certainly it's developers are targeted at > > making that better. > > tortoisehg (and tortoisegit) are windows only afaik, so if cross > platform compatibility is important to you, I can't see how can you > use those. > > > > > The Git GUI support is considerably more disjointed. Nothing is available > > that works transparently cross platform! The EGit plugin for Eclipse > still > > does not support submodules and is rather basic in it's other functions, > but > > now that I have my Eclipse/TortoiseHg setup working something like > stably, I > > am actually _almost_ back to the same functionality that I've had on CVS > and > > SVN repo's for many years, and on the whole can just access github and > > gitorious via that. > > yeah, the git submodule support for IDEs sucks: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=314853 > http://code.google.com/p/nbgit/issues/detail?id=38 (Netbeans) > http://youtrack.jetbrains.net/issue/IDEA-64024 > and the fact that the minority of the git users prefer the command > line over the guis doesn't help the issue. :/ > > > > > The jump to git by many projects had nothing to do with improving > > functionality and everything to do with jumping on 'this is the new > > sourceforge' bandwagon. The majority of the world uses Windows - it does > not > > mean it's the right answer to the problem ;) > > > > didn't occurred to you that maybe the developers behind those project > take those concerns into account, and they chose git because it was > worth it? > if you think that for your own projects SVN or even CVS is better > choice, then use those! > but for the php project, we have to find the best possible solution > suited for those who will be actually using the version control. > > our current problems with svn are pretty much laid out in the rfc > https://wiki.php.net/rfc/dvcs > I would add the fact that our current repo is pretty large(both in > data size and in history), so on a few occasions when I tried to > merge, or reverse merge, that was surprisingly slow. > Another thing which is not explicitly explained just implied: having > the ability to commint on your local clone also means that we could > keep the "blessed" repository more clean. > here is an example: http://news.php.net/php.pecl.cvs/16388 > > currently we have to keep patches around for contribution, with dvcs, > we could make the collaboration more fluent. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
