You've probably noticed that Git puts additional context data in the hunk headers: the lines that start with @@ and specify the line numbers where the hunk fits. For example, in the Rails Git repository, git show 13e7849 reveals the following two lines:

@@ -39,12 +39,7 @@ module ActionController #:nodoc:
@@ -67,6 +62,12 @@ module ActionController #:nodoc:

The algorithm Git uses to choose these lines is simple: search backwards for the first line with something other than whitespace in the first column, and use that. This works great for C, but as you can see above, it's not quite as informative when it comes to Ruby. Lucky for us, it can be customized with a two step process.

So I've been scratching my head about how to use all my custom config files when I'm using a machine without a dedicated user account (e.g., when pair programming). It recently dawned on me I could sidestep the issue by setting up a config directory in /tmp, pointing HOME to it, and launching GNU Screen. I hacked together a quick script I could run via curl -s http://c.tpope.net|sh that allows nearly instant setup on any system. It works beautifully on Linux but trying it on OS X has revealed several reminders why I haven't migrated.

In our previous post in the series, we took a look at how a Rails core committer could best pull in a branch submitted by a contributer. Today, we're going to be looking at things from the opposite side: How a contributer can best maintain a branch intended for pulling.

Before I continue on in my workflows series, I wanted to take a moment to elaborate on my earlier comments about commit messages. I think the best practices for commit message formatting is one of the little details that makes Git great. Understandably, some of the first commits to rails.git have messages of the really-long-line variety, and I want to expand on why this is a poor practice.

A few months back, I started a low profile project to create a set of Vim runtime files for various Git filetypes that would ultimately be included with Vim. Given the warm reception they have received, an official announcement seems prudent. Five different filetypes are provided: gitcommit, gitconfig, gitrebase, gitsendemail, and git (which is a generic filetype for things like git log output).

There's no formalized install procedure but the following shell commands should suffice:

mkdir -p ~/.vim
git archive --remote=git://git.tpope.net/vim-git.git HEAD|tar xf - -C ~/.vim

The files tagged with v1.0 are already slated to be included with the next Vim release, and those tagged v2.0 have just recently been submitted for inclusion.

Welcome to my series of articles providing example workflows for working with the Rails core Git repository. My first post is designed for Rails core committers and explains one way to deal with contributions that come in the form of a Git URL and a branch name.

The Ruby on Rails core is now hosted on Git. This is great news for Git fans like myself. For those of Rails core contributors who are coming late to the party, here's a quick list of tips I've put together especially for you. This no substitute for a proper tutorial but rather a Rails biased supplement to one.

Today I devised a little script to generate Ruby examples showing code and output.

% rubydemo '[1,2,3].inject {|m,o|m+o}'
[1,2,3].inject {|m,o|m+o} #=> 6
% rubydemo 1/0
1/0 #=> #<ZeroDivisionError: divided by 0>

Here's the script I used for generation. (It could have been one line if I didn't care so much about exception formatting.)

#!/usr/bin/ruby
print ARGV.join(" ") + " #=> "
begin
    p(eval(ARGV.join(" "),binding,"(demo)"))
rescue Exception => e
    puts "#<#{e.class}: #{e.message[/.*/]}>"
end

The real killer app, though, is using it in conjunction with IRC. Here's the alias I used in Irssi.

/alias rd exec -nosh - -out rubydemo $*

Now I need merely do /rd 2+2 to get a beautifully formatted 2+2 #=> 4 in any conversation.

An incredibly useful technique when using Ruby is to auto-load at start-up a custom library written for exactly that purpose. This is easy to accomplish with a couple of environment variables, but I see very little discussion on the subject. Thus, I've written a nice summary of how to go about setting this up.

Ever since I took up IRC, I've noticed an ever increasing tendency to substitute homonyms for other words in my writing. I used to never so much as confuse "it's" and "its", now I routinely catch myself typing "you're" for "your", "to" for too", and even oddities like "one" for "won." Not only has it directly affected my online discussions, I also find it creeping into other, more deliberate forms of writing. Discussing this with my fellow chatters has revealed other people having noticed this phenomenon in their own lives as well when they began to do more communicating online. I would like to propose the term "homonyslexia" to describe this curiosity. I choose this word both because I love clever word play, and because it has zero homonyms of its own. So what is the cause of "homonyslexia"? Is it because of constant exposure to other chatters who demonstrate less than stellar grammar and spelling? Or does the more rapid pace of online chat, as opposed to other written communication, allow us less time to reflect on word choice, with the sloppiness gradually seeping into other areas of our lives?