tail -f findings.out

Problem

You have a file already tracked in your git repository, but you don’t want future modifications to it to be tracked.

A perfect example of this is the DB config file for Rails projects (config/database.yml). You’ll probably want to track this to keep the production and staging configuration stored and consistent. But it’s quite likely that individual development configurations will be different. Having a commit for each developer adding their own local configuration and thereby polluting it for others when they push is just silly.

Solution

The fun details

I had initially thought that git-ignore was the thing to use for this. That was wrong: git-ignore’s purpose is to allow ignoring of untracked files. In the case of the Rails DB conf example above, the file is already tracked. It has the instance information that needs to be shared and now we want to add local development details. Since it’s tracked, any modifications are going to be picked up by git-status. When you do a commit including changes to tracked files listed in .gitignore, the changes do indeed get pushed, which isn’t what we want.

When looking around for solutions to this, I saw “git rm –cached FILENAME” suggested as a way to stop tracking currently tracked files. And it does this, but it also deletes the file in the commit, which isn’t what we want either.

git update-index allows you to alter your staging area more manually than usual. With it you can perform a wide range of operations not otherwise possible through standard commands. Continuing with the Rails DB conf example, here’s what the workflow would look like:

1. config/database.yml with permanent instance info is added, committed, and pushed
2. Application code is pulled down by new developer
3. Local modifications made to database.yml for new developer’s local DB setup
4. git update-index –assume-unchanged config/database.yml

Thereafter, the changes to conf/database.yml won’t appear in status or get committed. You can continue making and committing other changes, going about business as usual. But any changes to config/database.yml won’t ever appear.

In case you decide you do want to start tracking changes on a file previously ignored, just run:

Thereafter changes to FILENAME will appear in git-status.

Gotcha

The annoying part about this solution is that it has to be run against every new checkout of the repo with the files whose modifications should not be tracked. The command sets a particular bit per checkout, and it’s not passed on to new checkouts.

Just as I was finishing up some fact checking for this write-up, I came across Jesper Rønn-Jensen’s post on this exact topic. If only it had come up in my initial searches! Here’s hoping the next searcher has better luck.

[EDIT, 2009-12-20]: For some time I steered away from installing Rails via APT on Ubuntu systems. I ran into a number of annoyances early on trying to get various bits of Ruby, Rails, libraries, and others installed and working together properly. And along the way I just never tested the following on a fresh Ubuntu system:

That’s it. On a freshly baked Ubuntu 9.10 Desktop or Server, this will install (as of today):

• ruby: 1.8.7
• rails: 2.2.3
• irb: 0.9.5
• rake: 0.8.4
• rdoc: 1.0.1
• sqlite: 3.6.16
• rubygems: 1.3.5

And a host of dependencies of course. Perhaps I had simply FUBAR’ed my system by the time I tried this in the past, but it is working swimmingly now. Most of the other tutorials I’ve come across for Rails on Ubuntu take the more manual approach as well, but for now this looks like the way to go. For comparison, when I went through the more stepwise setup process using the script mentioned in the original content of this post below all the same versions were installed except for Rails itself, which was 2.3.5. So a slightly newer Rails version via gem than the Ubuntu repo, otherwise identical.

What follows is the original, more manual approach to getting everything installed. It might be useful to try if you run into problems with the repo package.

As I tried to get Ruby on Rails up and running on multiple (Jaunty Jackelope) Ubuntu 9.04 boxes, I came across a few… gotchas. While the steps described in this post will get Ruby, Rails and friends in place and working, there are a few places that have other potentially perilous options resulting in much gnashing of teeth.

What follows are the commands needed to get Rails working on a fresh Ubuntu 9.04 (server) box. To save some copying and pasting you can use this script which sets everything up and provides logging.

Warnings:

• Don’t install gem with apt-get. This is not RubyGems. And don’t even install rubygems via apt-get. Install it from RubyForge.
• Don’t forget to make the symlink from gem1.8. This can cause no end of pain if you didn’t listen to the last warning.
• After RubyGems is in place, install Rails and other related items you need with it. Don’t use apt-get for these.

For more information on setup, covering DB and web server options on Ubuntu, check out the Community Guide.

[EDIT, 2009-10-04]: I just tried starting up Rails installed through the process above on a fresh Ubuntu 9.04 desktop. Turned out I also had to install libopenssl-ruby via apt-get. This is apparently due to some splitting of packages in the Ubuntu repo.