The fact that I prefer a GUI for source control management (Tower for Git and Versions for SVN) probably marks me as a lightweight, but I've found them to be valuable for 2 reasons:
1. I write better commit messages when I use them because they spellcheck and it just _seems_ like I ought to use proper punctuation and capitalization.
2. Having a one keystroke / button diff from the previous version offers a good sanity check to myself and helps me catch stupid errors from being committed to source control.
That being said, I still usually end up using a mix of the GUI and command line for some of the other features.
For me, the big win are the source control DAG visualizations. `hg glog`, `git log --graph`, and `tig` are great 80% solutions, but at the end of the day, I strongly prefer the displays provided by MacHG and GitX.
There is really no reason to feel embarrassed because you use a GUI. A terminal is a terrible vehicle to display the complex information that git needs to show you, especially `status`, `diff`, etc...
To me, git GUI's are like IDE's: they make you more productive, so you'd be a fool to ignore them.
OS X has some great Git GUIs, and Linux has a few good ones, but there don't seem to be many polished ones for Windows? I use Git Extensions, but it feels a bit rough compared to TortoiseHg. Does anyone know how TortoiseGit is coming along?
My significant other was very happy with SmartGit on Windows before she switched to Mac. (Since SmartGit is a Java application, it should work on all platforms with the JRE and git.)
That's pretty close. In reality, I started working at a company where I was a fulltime Cocoa programmer. Working on a similar project in my free time just didn't seem that attractive anymore.
Have you considered "blessing" another branch, adding a supplimentary commiter or pulling in changes from one of the other branches so that the mainline is more up to date with a compiled binary? In any event I appreciate your tool and thank you for doing it!
It's probably my ignorance of github but there really does not seem to be a great way to pass the torch on or see what the other forks have done without going into each fork.
It's difficult to keep track of all the various branches, is there a reason you haven't transferred the project to someone who can create a new proper release, update the website, etc?
GitX is simply awesome, but unfortunately I've left the official one behind and moved to the one maintained by laullon [1] because it contains more of the features I want, and seems to be updated a lot more.
You may want to try tig (http://gitready.com/advanced/2009/07/31/tig-the-ncurses-fron...). The main view has the same info (may have to hit g to see the graph), plus it lets you drill down into each commit. All without leaving the comfort of your terminal.
I like tig, but my main use for a git gui is to manage my set of staged files (when I'm not adding everything), and for some reason tig doesn't let me discard untracked files (I can either add them or leave them untracked).
Anybody know a workaround? I suppose I should figure out how to patch it and send a pull request.
One thing I am curious about (genuinely curious!) is how so many of the mac git GUIs are closed-source and/or paid apps. The original CLI git client is GPLv2, IIRC.
Are the mac clients calling the git command line tool, have they re-implemented the git file manipulation routines, or are they using some other means of manipulating the repository files?
I'm just interested to know which approach they chose.
I'm pretty sure they're calling the git command line tool. As far as I can remember, I've had to tell all of the ones I've tried where to find the git command.
Note that git is designed for people to build things on top of it, including GUIs, by using the command line tools. The git commands generally come in two flavors, called plumbing commands and porcelain commands. The later are what users of git are meant to see. Their interfaces are not necessarily stable. The later are kept stable and often have input and output designed to be machine friendly.
There are plumbing commands to do very low level repository manipulation, perfect for GUIs to use.
I'm sort of fascinated by this, but out of all the git GUIs I've tried on Mac except for GitX work backwards from how I want/need them to work. I live at the command line, but I do like having a nice GUI for staging commits and viewing history.
GitX works perfectly for me in this regard. It's simply `gitx -c` from the current directory to open a nice GUI for staging files (or pieces of files) and composing a commit message or `gitx` to view the history of the current repo. And it's fast, so launching it does not get in my way too much.
All of the other ones I've tried have had poor command line integration and wanted me to tell them about my repos ahead of time. I guess maybe that reflects the needs/workflow of the majority of people who want a nice OS X GUI for git, but it doesn't work at all for me.
A couple of notes:
Article is from Decmember 2010, Git Tower is now longer in beta.
Also Xcode 4 is out with built-in Git support. Not sure if it counts in this context, but worth mentioning anyway.
Asking friends about git GUIs I found out a strong correlation between not using a GUI for git and not using proper commits[1]. I feel sad when I hear the words "Oh, I just commit everything!"
[1] By proper commit I mean one where you have a proper commit message per file (or group of files) per purpose and not just a commit message for all the changes you made during your daily work hours.
While we're on the topic of GUI DVCS clients for the Mac, does anyone have any recommendations for Mercurial? The last one I tried didn't have serve functionality nor provide a commandline client...
36 comments
[ 3.1 ms ] story [ 81.0 ms ] thread1. I write better commit messages when I use them because they spellcheck and it just _seems_ like I ought to use proper punctuation and capitalization.
2. Having a one keystroke / button diff from the previous version offers a good sanity check to myself and helps me catch stupid errors from being committed to source control.
That being said, I still usually end up using a mix of the GUI and command line for some of the other features.
To me, git GUI's are like IDE's: they make you more productive, so you'd be a fool to ignore them.
It's probably my ignorance of github but there really does not seem to be a great way to pass the torch on or see what the other forks have done without going into each fork.
Thanks for the suggestions on the other branches. :)
[1] https://github.com/laullon/gitx
Anybody know a workaround? I suppose I should figure out how to patch it and send a pull request.
Are the mac clients calling the git command line tool, have they re-implemented the git file manipulation routines, or are they using some other means of manipulating the repository files?
I'm just interested to know which approach they chose.
There are plumbing commands to do very low level repository manipulation, perfect for GUIs to use.
GitX works perfectly for me in this regard. It's simply `gitx -c` from the current directory to open a nice GUI for staging files (or pieces of files) and composing a commit message or `gitx` to view the history of the current repo. And it's fast, so launching it does not get in my way too much.
All of the other ones I've tried have had poor command line integration and wanted me to tell them about my repos ahead of time. I guess maybe that reflects the needs/workflow of the majority of people who want a nice OS X GUI for git, but it doesn't work at all for me.
Just sort of interesting.
I've never found myself wanting "iTunes for your git repos" nor could I figure out why anyone would ever want that.
[1] By proper commit I mean one where you have a proper commit message per file (or group of files) per purpose and not just a commit message for all the changes you made during your daily work hours.