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.
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:
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:
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.
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
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.