I anticipate enjoying git submodules for all of the various and sundry dependencies for my project. However there is a bit of a gotcha with my specific use case. It’s seems I’m not alone, but I thought I’d write this up for others who may into the same thing (and for my own future reference).

The issue happens when you have a directory that is checked into git and you decide to delete the directory of checked in files and add a submodule instead. Seems like a common use case to me, but perhaps the creators of git submodules didn’t thinks so. This happened to me in the move from subversion to git. Initially, all of the plugins were accessed as svn externals; however they were not available via git and I wanted to do one migration at a time, so I just checked the source of all of them into vender/plugins. Later, I dug up references to various git repositories where the plugins are now available, and created subrepositories — awesome, right?

The gotcha comes when I switch branches back and forth between the “master” (no submodules, but with checked in source) and “dev” (where my submodule work is). Here’s what happens:

$ git checkout master
error: Untracked working tree file 'vendor/plugins/acts_as_list/lib/active_record/acts/list.rb' would be overwritten by merge.

Here’s my workaround…
To go back to a branch w/o submodules

$ rm -rf vendor/plugins
$ git checkout master
$ git checkout vendor/plugins

To go back to a branch w/ submodules

git checkout dev
git submodule update --init

Update: another gotcha, when I tried to merge dev into master I got “fatal: cannot read object… It is a submodule!” found the answer here and it worked for me:

git merge -s  resolve

For the record, I’m working with git version 1.6.1

I just went through a fabulous tutorial by Daryn Holmes about routes. It is written for 2.0.2, but I found that nothing had changed for 2.2. I already had a good feel for how routes worked, but stepping through the details was very helpful.

Key points:

  • By default controllers render the view that has the same name of the action invoked.
  • index is the default action

Debugging Tips:
You can quickly see where a route ends up by typing this into irb:

>> rts = ActionController::Routing::Routes
>> rts.recognize_path("/")
=> {:controller=>"albums", :action=>"index"}

You can also go in the reverse direction to see what URL would be generated by a route. To see what URL an action will end up at:

>> rts.generate(:controller=>'albums',:action=>'index')
=> "/music"

How could I have lived for so long without knowing that I could set up my command line with vi key bindings? Well, for anyone else who uses vi and bash, here’s the secret…

Create ~/.inputrc

set meta-flag on
set input-meta on
set output-meta on
set convert-meta off

add this to your .bashrc

set -o vi

Thanks Adam!