A while ago I wrote about a script I'd written that I called gp which addressed a frustration I had about, essentially, starting work. What gp did was eliminate all the drudgery involved with opening iTerm tabs (yes I still use it in preference to Terminal.app despite it's occasionally freezing up for a few seconds under Leopard), changing directory to my project folder, and running lots of different commands for editors, browsers, version control, and so on.
The gp script had many deficiencies, some of which were addressed by Solomon White who made his own version that worked with Terminal.app. But neither script was ideal and we agreed that, at some point, it would make sense to pool our efforts.
Pressure of work meant I didn't look any further at it until last weekend when I found myself compelled to build a new version of gp which I have called godo which stands for:
go (to project) do (stuffs)
So you might type:
godo godo
and godo would search among the project root folders you had defined for a likely match, then using heuristics identify it as, say, a ruby project, and run a set of actions defined for ruby projects. The heuristics are pure ruby expressions, here is the heuristic for detecting a rails project:
rails: |
File.exists?( File.join( project_path, "config", "environment.rb" ) ) &&
File.exists?( File.join( project_path, "config", "environments", "development.rb" ) ) &&
File.exists?( File.join( project_path, "config", "environments", "test.rb" ) )
the default configuration comes with heuristics for Rails, subversion, git, and rspec and a set of actions that you might want to perform in various combinations. New heuristics, actions, and groups can be specified right into the configuration. Alternatively a per-project configuration can list a custom set of actions to be run for that project.
When writing godo it was important to me that it be a gem from the start so I turned, once more, to hoe when building it. I've tried to address all the issues that had made gp unwieldy like it's use of a pre-built folder index (that was never up to date), the clumsy configuration, and the lack of separation from iTerm. This last turned out to be very useful.
This was also a good opportunity for me to test out GitHub. From the beginning I made godo available as a GitHub project. I was surprised and delighted when Lee Marlow forked godo and pushed up a bunch of changes including Terminal.app support, depth pruning, and per-project configuration.
It meant I had to figure out how to add Lee's repository as a remote with a local tracking branch:
git remote add lmarlow git://github.com/lmarlow/godo.git
get fetch lmarlow
git branch --track lmaster lmarlow/master
take a look at the changes he'd made:
git log -p master..lmarlow/master
then merge them into my own branch for release:
git merge lmaster
git push origin master
I might have preferred to cherry pick his changes and integrate them separately but it felt like a bridge too far, for me, in Git terms. I was just pleased finally to have his changes integrated.
godo is, i think, more or less ready for serious use. If you want it:
sudo gem install godo
to get the latest version (1.0.5) which supports both iTerm and Terminal. If you like it please leave a comment or something. And if you find bugs or missing features, you are welcome to fork the project and push some changes!
My thanks to Lee Marlow & Solomon White for their contributions, and to Tom Copeland for resolving the RubyForge pickle I created for myself.