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.

piecemeal staging

This is a follow up to the comments from yesterday’s article about interactive adding. Readers were begging coverage of powerful git add -p, a shortcut to the patch mode of interactive adding. This command is capable of breaking up changes in files into smaller hunks so you can commit exactly what you want, and not just the whole file.

This behavior is very helpful since it allows you to version any “hunk” of text in the file that you’d like. Perhaps that one line of code will break the build on others’ machines or the build server, but just not yours. You get the point.

Let’s go through an example of using it, making changes to our project’s trusty README file again. Here’s what git diff gives us from the changes that were just made:

diff --git a/README.md b/README.md
index 2556dae..45d8b6e 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,14 @@
> There is only one way...
> ~ Henry Van Dyke
   
+# Project information
+
+Blah blah blah...
+
# Want to contribute?

If you have ideas about... 
+
+# About
+
+This blog is just awesome.

So as we can see, we’ve made changes in separate parts of the file. However, I want to only commit the lower half. Besides, who really needs documentation anyway? Enter:

git add -p

Run this and you’ll be greeted with a prompt just like git add -i, but it has quite a few options:

Stage this hunk [y/n/a/d/s/e/?]? ?
y - stage this hunk
n - do not stage this hunk
[... removed a few ...]
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

Most are pretty self-explanatory, but let"s go over the really cool ones. What we really want is the s option, which will split the file into two smaller hunks of code, one for the higher “Project Information” block and one for the “About” block. Once it"s split it will prompt you with just the changes for that hunk:

Split into 2 hunks.
@@ -1,6 +1,10 @@
> There is only one way...
> ~ Henry Van Dyke

+# Project information
+
+Blah blah blah...
+
# Want to contribute?

If you have ideas about...
Stage this hunk [y/n/a/d/j/J/e/?]? n

From here we can ignore it with n, and move on to the next one and add it with y:

@@ -4,3 +8,7 @@
# Want to contribute?

If you have ideas about...
+
+# About
+
+This blog is just awesome.
Stage this hunk [y/n/a/d/K/e/?]? y

Doing a git status will show changes to be committed and changes to be staged on one file. Strange, but it makes sense: we staged half the changes, and the other half are not yet added to the index.

There’s also the e option, which will let you to manually flip the hunks on and off in your favorite editor. Instructions are included with that option, so go play around with it when you get the chance. (No pun intended.)

If you’ve got any stories as to how git add -p has helped you (or if a neat feature was missed), let us know in the comments!

interactive adding

Sometimes simple adding with git add . or git commit -am just isn’t enough. You may want to split changes up over several commits, or you’re just not ready to add everything yet. And who wants to add individual files one at a time? That’s just boring. Enter the interactive adder:

git add -i

Let’s go through an example of using the interactive mode. I made some changes to the gitready project’s readme along with another file. Calling the above command gives us this output, the status of the index:

         staged     unstaged path
1:    unchanged        +3/-1 README.md
2:    unchanged        +1/-1 _layouts/default.html

*** Commands ***
1: status   2: update  3: revert  4: add untracked
5: patch    6: diff    7: quit    8: help
What now> 

As you can see, we have plenty of commands available to us. If we want to see this screen again, using the status command will bring us back. The +3/-1 are the number of lines that have been added/removed, the usual plus and minus symbols that you see when pulling.

Let’s add the changes we made to the readme. Using the update command will allow us to do this. After choosing this command we’ll see this output:

           staged   unstaged path
* 1:    unchanged      +3/-1 README.md
  2:    unchanged      +1/-1 _layouts/default.html
Update>>

And if we select to update 1, will notify us that the file is staged to be committed. Now if we look at the status, you can see that our readme has been staged properly.

          staged  unstaged  path
1:        +3/-1    nothing  README.md
2:    unchanged      +1/-1  _layouts/default.html

Once you’re done, you can dump out using the quit command, and commit your work. If you don’t trust the adder, calling git status will show that only the readme has been staged for the commit:

# On branch master
# Changes to be committed:
#
# modified:   README.md
#
# Changed but not updated:
#
# modified:   _layouts/default.html

There’s plenty of other helpful commands that the interactive adding can do, this is just the start. Check out the help command for the rest that’s available to you. We’ll have more tips in the future for the other commands available inside interactive mode.

visualizing your repo

So, you want to see your repository in a brand new way. You’re sick of the command line, you need to see some graphs! Pixels! Buttons! Graphics! Dialog boxes! Ok, we get the point.

Our first option is viewing your repo in a browser. This functionality is packaged with most git installs:

git instaweb

This will fire up a server, usually lighttpd, to serve a simple web interface for your repository. You can browse commits, trees, view files, what have you.

This is really useful if you need to dive down and see history but you don’t know the commands yet. (And it’s easier too.) If you don’t have lighttpd installed and don’t want to bother with it, running

git instaweb --httpd webrick

will force WEBrick to serve the page, which will work just as well if Ruby is installed on your system. It also works with Apache, just check instaweb’s manpage to see the supported server and other goodies.

Webpages are great and all, but what if you want to see your commits in a more…graphical manner? Look no further than gitk or gitx then. These programs give you a more dynamic view of your repository and let you actually see branches and merges take place:

Need some graphical git loving? Use gitk with most git installs by running gitk or download gitx for OSX. Windows users, if you know of an equivalent, comment away!

There’s also plenty of git graphical love over at GitHub for every project, be it visualizing the impact individuals have had on the project, times that people have worked on the project, and even more. Definitely play around with various graphs they have to offer if you haven’t yet.

There’s also plenty of other good visualizers over at the GitWiki. If you know of any other good ways to see your repository graphically, let us know in the comments. I’ll continue to update the post with more and better knowledge as it becomes available.