We can do it. We’ve been doing it. We’re doing it right now.

The first thing you’ll need to know is that Git has hooks. Lots of them. They live in the hidden ‘.git/hooks’ folder in your project. Their names are relatively descriptive and tell you when these hooks will fire. The one we’re particularly interested in right now is ‘.git/hooks/post-commit’.

Open up that file, there’s stuff in there, delete it and add the following hotness instead:

Once you’ve updated your account, username, password, and the group to which you want to send your messages - you need to make this bad man active so it will fire at your will. The zombies will never see it coming:

chmod +x .git/hooks/post-commit

Keep in mind that none of these hooks will fire unless they are marked as executable. This will bite you; it did me, and I’m still recovering. It’s okay son, that’s how we earn our stripes.

Make some changes, queue ‘em up, hit commit, and BLAM: you’re knee deep in dead zombies and commit messages! But how do you kill something that’s already dead…

OMG - WHAT IS THIS CRAP IN MY CONSOLE?

I know these don’t come with RSpec because ‘rake spec’ is silent (because we don’t have any specs yet — which is fine, we’ll build them later, don’t worry). This little thing has annoyed me for a while now but I’ve just had more important things to do instead of digging in and figuring out where this output is being generated, you know, like client work, the stuff that pays the bills.

Today, I took the time to figure it out and it was crazy simple. I’m kicking myself for not checking it out sooner (I feel like such a dirty noob *shakes head*). It turns out that each one of these blank lines represents one level in Test::Unit - unit, functional, and integration. Since I delete the “test” folder on sight (in new projects using RSpec) there aren’t any tests to run and this is actually part of the default output each Test::Unit  run.

Now that we have an understanding of what’s going on here — we have to dig in a little more and figure out where this rake task is being defined. Since Test::Unit is being fired off when we call a ‘rake’ by itself it means that there is a default rake task (’task :default => :sometask’) specified somewhere that is causing this behavior. Another thing I tend to do in my applications is freezing Rails so I don’t have to depend on the version of Rails lives on each machine on which this app is hanging out. This allows me to search through the Rake tasks that come with Rails by default. A good portion of these tasks live in ‘railties’ (general framework utilities) so we can start our search there (in ‘vendor/rails/railties/lib/tasks’ - because ‘lib/tasks’ is where Rake tasks tend to live). In order to search for ‘:default’ within Railties we’ll bust out our trusty friend ‘grep’:

That grep command says: search inside all files ‘-R’ found in ‘vendor/rails/railties/lib/tasks’ for any line containing ‘:default’ and show the line number ‘-n’.

BINGO! There it is! All you need to do is edit ‘vendor/rails/railties/lib/tasks/misc.rake’ and comment out line number one. Then if you run the default rake command ‘rake’ (by itself) you should no longer have to endure the filthy remnants of the Test::Unit.

I want to talk about RSpec syntax highlighing in Vim or my apparent lack thereof.  Check it out:

Missing RSpec keyword syntax highlighting

I’m using MacVim with the vim-ruby gem installed. There has to be an easy way to get RSpec syntax highlighting for all the RSpec keywords although I couldn’t fine one after spending time scouring the Google. Time to break out the ‘Hard Way’.

That SEXY theme you see is a modified port of the TextMate theme called Monokai.  It’s was originally ported to Vim by Thomas Restrepo. Monokai forms a solid basis for some supurb eye candy but my taste requires a bit more flare.

BEHOLD: Monokai Modified for Vim and Monokai Modified for TextMate. It’s rumored that more than a few retinas have been burned by the Monokai - shhh, don’t listen to them, trust me, it’s great!

Anyway, we’re drifting again, let’s continue.

It was a pain to figure out how to tag things with the proper colors when working on a new vim color file. After quite a bit of initial pain I found SyntaxAttr.vim and it made my Vim themeing life quite a bit more enjoyable. SyntaxAttr will tell you the exact syntax highlighting attribute Vim is using to attach a color to an element. In the case of RSpec ‘description’ and ‘it’ keywords Vim was telling me: “<no syntax group here>”. Bummer.

Now we have to go in and force Vim to recognize these keywords as syntax so we can hang colors off of them. You can do this using ‘after’ syntax files. This will allow you to add to an existing syntax file without modifying the original. You can see a more detailed explanation of this in the Vim documentation for syntax files.

I chose to override the ruby.vim syntax file. I did this by creating a blank ruby.vim syntax file in ~/.vim/after/syntax/. You may need to make the after and syntax directories if they don’t already exist. This is what I put into my ruby.vim override file:

UPDATE: This code from Tim Pope (via Josh Nichols in the comment) is better as it will only apply this formatting for ‘_spec.rb’ files. Thanks Josh!

This is just standard syntax file stuff: the first two lines are searching for matches and the next two lines are assigning them to an existing syntax structure.

(If you don’t want to piggy-back on an existing syntax definition [as I've done here] you can take a look at your theme in ~/.vim/colors for the proper way to add a new definition.  Instead of specifying “Define” you would specify your new definition.)

The override ruby.vim finds lines starting with “describe” and “it” and assigns them to the “Define” syntax definition. In Monokai Modified this is HOT PINK (as it should be):

Correct RSpec Syntax Highlighting in Vim

Sweet. We’re in business.