I'm about to start development of a Rails 2.0-powered web application as part of my work in the Reflective Living group at Arizona State University's Arts Media and Engineering program. Previously, we've used trusty standby subversion for version control, but there's a lot of hype in the rails blogosphere about git, so I decided to give it a shot. One of the most interesting things about git, compared to svn, is that it can be used without a server. Since I don't have the admin access needed to create a new repository on our department svn server, I decided to put my local copy (the only existing copy as now) of the new project under git. First roadblock: my work development machine is a Mac Pro running 10.4.11, but there is no 10.4 build of git available from the main distribution page.
After a quick google, I came back to macports, which is my go-to point for installing almost any unix-world software these days. It's a system based loosely on the bsd port concept, but from an end-user perspective it operates similarly to apt-get, which I'm familiar with from debian/ubuntu. I know somebody out there is probably pulling out their hair and screaming "but wait, apt-get distributes binaries; macports actually downloads and compiles the source." I realize the difference, but from my perspective, I type one command for either program and the dependencies are fetched and compiled, and that's good enough for me.
Anyway, installing macports is pretty much simple. There're instructions on the macports homepage, and they're reasonably complete. The only gotcha I've ever encountered is that sometimes, for some reason unknown to me, the installer fails to add the /opt/local/bin and /opt/local/sbin paths to your ~/.profile (the file that tsch executes on startup to set environment variables). In that case, you just need to edit ~/.profile in your text editor of choice to add the line "export PATH=/opt/local/bin:/opt/local/sbin:$PATH" (without the quotes). You'll need to open a new terminal window for the changes to take effect.
Next, install git-core. The command is "port install git-core" . This may take a few minutes, so feel free to get some coffee, refresh google reader, or otherwise relax.
So, now I had git running on my local development machine. It's relatively similar to svn in many ways, and there is a great transitional document available that explains similarities and differences among svn and git. One thing I find very cool are the gitk and git-gui commands, which provide two different guis for git functionality. Happily, they both run on OS X (both 10.4.11 and 10.5.3) with no additional work when compiled by macports as part of git-core.
So, running a scm package on asingle machine is great fun, and very handy if you want to tag stable versions of your work in case you botch something up trying to implement a new feature. However, it doesn't help with the traditional collaboration-support role of svn, where multiple developers can concurrently work on the same version of the code, with conflict resolution and other neat collaborative tools.
Subversion is designed from the ground up to be multi-user; git is sort of different. I actually had to google around for some time to work out how git-as-server-for-multiple users works. There's git-daemon, which provides anonymous read-only access to git and git-shell, which is a limited shell providing more controlled access which can be configured as a unix user account's shell. I needed the ability to make repositories access-controlled, so git-daemon is right out. Git-shell sounds better, but the idea of setting up lots of different user accounts on my machine for the sole purpose of allowing my collaborators to log in to git-shell struck me as unnecessarily annoying. Then, I found gitosis.
This python-based tool provides access control for git repositories based on RSA keys, through a single extra user account. Good times, I say. However, as with many things git, the OS X install route isn't entirely clear. Scie.nti.st has a very thorough how-to for gitosis setup on linux, but it doesn't address the OS X end of things.
Trying the command from the article to install gitosis (python setup.py install) resulted in an error about missing setuptools. I'm not a Python developer, so I was a bit confused. What's setuptools? Turns out setuptools is a Python plugin -- or whatever Python folks call software that extends the functionality of the language -- that makes permanently installing packaged python scripts easier. Bottom line: it isn't available in Python 2.3, which ships with OS X 10.4.
Okay, so no big deal, right? Macports has python25 and py25-setuptools. However, if you read the scie.nti.st writeup, you'll notice a caveats section suggesting that gitosis does not like to live in a non-default path. Heed this caveat. Trust me on this one. Thar be dragons. I successfully installed python 2.5 and setuptools through macports, then ran the gitosis setup command, created the git user/group, and proceeded to get a lot of really noxious python errors about paths when attempting to continue with the scie.nti.st tutorial. Bad mojo.
So, okay, gitosis really wants to be in a more standard location. Thankfully, macpython.org has a Python 2.5 distribution (first item on that list, as of this writing) that includes setuptools and installs as an OS X mpkg. Now, this also puts Python in a weird place, so I'm not sure why gitosis is more okay with this than with the macports route, but it is. Second useful link I found was an OS X Leopard gitosis how-to that explains how to set up an OS X user for git and provides a bit more clarification on OS X specific details covered by the scie.nti.st article. While the tutorial is targeted at Leopard, it worked for me after installing Python 2.5 on OS 10.4.11.
After completing the setup, refer back to the scie.nti.st article for setup and usage. I really haven't done anything with my gitosis repository yet, but I thought I'd share the solution to my woes for anyone trying to set up a gitosis server on older OS X.
tags:
Design ©2005-2007 R. Spicer / Alterscapes.
Content licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.