Literate Programming

Meta

Table of Contents

Run Rails with custom patches

4 October 2012

I often see comments like this
in the Rails bugtracker. Generally, someone is running an older version of
Rails, and some bug they face has been fixed on edge. But they may be running
a version that's too old to recieve fixes, or need a fix that has yet to be
included in an actual release. What to do?

Luckily, Bundler exists. It makes it super easy to
run your own Rails. Check it out:

Step 1: Fork you!

Go to GitHub, hit up rails/rails, and click
that fork button. My own personal fork of Rails is
here, for example, so in the rest of
these examples, I'll be using my own username. If you're me, you can use it
too, but seriously, stop being me. If you're not me, substitute your own
username.

Step 2: apply patch

Let's get our copy going locally:

$ git clone git@github.com:steveklabnik/rails.git
$ cd rails

We'll apply the patch from the example comment above. In this case, the person
wants to have this patch work on Rails 3.1.

You have two options here: Rails keeps a branch open for every minor version,
and also tags every release. You can pick between the stable branch and a
particular release. The stable branch should work just fine, but maybe you're
on a specific Rails release for a reason. For example, the latest version of
Rails 3.1 is 3.1.8, but this person says they're on 3.1.1. If they use the
3-1-stable branch, they'll also get all the changes from 3.1.1-3.1.8, as well
as unreleased changes that may exist on that branch. That's possibly too much
for you, so we'll just work off of 3.1.1. This is probably a bad idea, since
3.1.6 included several security
fixes,
but you're an adult, do dumb things if you want to.

$ git checkout v3.1.1

You'll see a big message about a detached HEAD. Don't worry about it.

If you want the stable branch for extra fixes,

$ git checkout 3-1-stable

Now, it's a good idea to make our own branches, so that we don't get confused
with upstream. So let's make a new branch:

$ git checkout -b my_patched_rails

Awesome. Now, we can grab the commit we wanted. We can do this with
cherry-pick:

$ git cherry-pick 8fc8763fde2cc685ed63fcf640cfae556252809b

I found this SHA1 by checking out this
page, which is linked at the
top of the pull request.

If there are multiple commits you need, you can do one of two things: either
cherry-pick the merge commit, in which case you'll probably need to pass
the -m1 option, or simply cherry-pick them all in order.

You may get conflicts. Yay backporting! If git whines at you, do what you
normally do. Resolve the merge, then git commit.