Rescuing Your Ruby on Rails Projects

Ruby on Rails has been around for about 5 years and in those years developers have created a lot of applications. Many of those applications were created while learning Ruby and Ruby on Rails and may not have used the best practices but yet made it into production web sites. These web applications can be problematical but a new book focused on the solution is available. By Robert Bazinet

Presentation:Bindings, Platforms, and Innovation

Bob Frankston offers a vision of the Internet that focuses on communication and connection uninhibited by artificial barriers like carrier exclusivity, arbitrary differences in protocols, and vendor constraints. He uses stories as his organizing and presentational metaphor to share a vision of what could be, if we had free reign to follow our imagination. By Bob Frankston

Low Pro for Prototype and Firefox 3.5

Just a quick note for those googling for a solution to this. Older versions of Low Pro for Protoype will be experiencing problems with behaviors in Firefox 3.5. This issue has been fixed so pick up the latest version from GitHub

An interesting upshot of this is that I found out something pretty nice which is kind of obvious but had never occurred to me before. If you create a function in a closure then that function can refer to itself because it has access to that closure’s variables. I normally use arguments.callee to get a reference to a function from within its body but there’s never really any need to do that:

(function() {
  var aFunction = function() {
    aFunction.thing = 47;
  };

  aFunction();

  alert(aFunction.thing); //=> 47;
})();

stashing your changes

Stashing is a great way to pause what you’re currently working on and come back to it later. For example, if you working on that awesome, brand new feature but someone just found a bug that you need to fix. Add your changes to the index using

git add .

Or add individual files to the index, your pick. Stash your changes away with:

git stash

And boom! You’re back to your original working state. Got that bug fixed? Bring your work back with:

git stash apply

You can also do multiple layers of stashes, so make sure to use

git stash list

To check out all of your current ones. If you need to apply a stash from deeper in the stack, that’s easy too. Here’s how to apply the second stash you’ve got:

git stash apply stash@{1}

You can also easily apply the top stash on the stack by using (Thanks jamesgolick!):

git stash pop

A note with this command, it deletes that stash for good, while apply does not. You can manually delete stashes with:

git stash drop <id>

Or delete all of the stored stashes with:

git stash clear

checkout tracked remote branch

I frequently need to do this when setting up or syncing my various machines, and I seem to forget the command all the time. So let’s say you’ve got more than one branch on your remote, and you want to bring it down into your local repository as well:

Viewing information on the remote should look something like this:

$ git remote show origin
  * remote origin
    URL: *************
    Remote branch merged with 'git pull' 
      while on branch master
        master
      Tracked remote branches
        haml master

Luckily, the command syntax for this is quite simple:

git checkout --track -b 
  <local branch> <remote>/<tracked branch>

So in my case, I used this command:

git checkout --track -b haml origin/haml

You can also use a simpler version:

git checkout -t origin/haml

reverting files

This is a topic that is a constant source of confusion for many git users, basically because there’s more than one way to skin the proverbial cat. Let’s go over some of the basic commands that you’ll need to undo your work.

So, you just want to revert one file back to its original state:

git checkout <file>

One problem with this is that you may have is that a file and branch named the same. Since the checkout command is used for both reverting files and swapping out to a different branch, you’ll need to use this syntax (thanks, Norbauer)

git checkout -- <file>

If you want to throw out all of the changes you’ve been working on, there’s two ways to do that.

git checkout -f or git reset --HARD

Once these commands are run you’ll lose all of the work that isn’t committed in your directory, so make sure to take caution when using them.

Also, be aware that ‘git revert’ is not equivalent to ‘svn revert’! git-revert is used to reverse commits, something another tip will cover in the future.

fixing broken commit messages

You just committed that awesome feature/test/bug, but something just isn’t right. Either some information isn’t filled out, the commit message is wrong, or something else is just messed up. Let’s go over what can be done to fix the associated data after the fact.

Fixing the previous commit is very simple. Just use

git commit --amend

And that will fire up the commit patch in $EDITOR for you to mess with. Simply edit the message right on the top line of the file, save, quit and you’re done.

Now let’s say you’ve got a few commits to fix, or the commit that is broken is a few commits back. This process is a little more complex, but isn’t too bad. (Thanks to Evan Phoenix for this one.)

Here’s the scenario: the last 3 commits don’t have the right username, email, or perhaps commit message. Let’s start by generating patch files for the commits:

git format-patch HEAD^^^

That will generate files in the form of 0001-commit-message that contains the commit diff and metadata. One note with the 3 caret symbols: just add one for each commit you need to go back, and be consistent! EDIT: You can also refer to past commits with the syntax HEAD~n, so for this example we’d use HEAD~3. Go ahead and edit these files so they have the proper information. Once that’s done, we’ll need to reset our repository back a few commits:

git reset --hard HEAD^^^

Now we can apply each commit to fix the information. Make sure you do it in the right order! (Usually it’s ascending)

git am < 0001...
git am < 0002...
git am < 0003...

Now if you check git log you should see the right information. If for some reason stuff got messed up, doing a

git reset --hard origin/master

will bring you back to your original changes. Once you’ve got the information fixed, you’ll need to do a force push on the repo:

git push -f

If you don’t add the -f, git will complain. WARNING! Just be aware that modifying commit messages may muck up other’s repositories and should be used with caution. In fact, other developers may flat out hate you for doing this. If it’s far back enough it’s probably a bad idea to rewrite history anyway.

If you know of any unexpected or uncovered consequences please let us know in the comments. Another tip in the future will cover fixing the actual committed files and making sure that all repos are up to date.