Just Go Ahead and Write the Test

07.05.2012 23:37 by kbeckman | Comments

Recently, I’ve found myself in a couple of rework or debug situations where I’ve really wished that I had taken a few extra minutes and written a test or two to prove the code in question actually worked at one time… Both situations were outside of what I would consider the “normal” day-to-day unit testing scenarios where I’m covering typical model or controller logic. One situation involved dynamic routes created by OmniAuth and the other involved a local Git submodule for a gem I’m working on.


Adding the route tests was an easy fix, but it took me a couple days worth of recommitting the same submodule pointer updates in our base repo before I finally got sick enough of re-doing it. It helped to finally figure out why it kept happening too… One of the other devs on the team had re-cloned the project repo and forgot to do the submodule init/update steps. Every time I would commit, I would update the submodule commit pointer. Every time he would commit, it would roll the commit pointer back to a previous version. One RSpec test put an end to all of the commit games…


require 'spec_helper'

describe "Git Development Submodule" do

  it 'should have the latest commit id' do
    submodule_status = `git submodule status`
    error_msg        = 'Solution: git submodule update && git submodule init"

    # Ensuring the [git submodule status] command actually produces a result...
    # TeamCity tests are run under a build agent where source code is copied to rather than updated/fetched in a git
    # repo. This is a local dev machine test only...
    if status_msg.present?
      status_msg.should include '24a1c1299....', error_msg

  • Just shell-out using the git submodule statuscommand which returns the current submodule commit ID.
  • Notice the check for a status message before checking the commit ID. Depending on your build server configuration, you may not get a value for this when running in a CI scenario…

Configure DiffMerge for Your Git DiffTool

07.08.2011 22:57 by kbeckman | Comments

A while ago I wrote about the importance of choosing cross-platform development tools when available. As a consultant, being able to work proficiently with multiple platforms provides flexibility in the projects you can choose from. The ability to take a familiar tool with you from one platform to another saves you from having to ramp up on an alternative you’re not used to. It also adds value for your clients allowing you to concentrate precious time on ramping up on the more important domain knowledge specific to the project.


DiffMerge is an excellent diff tool that works on all platforms and one I’ve recently adopted as my primary diff tool. Git is easily the best source control system under the sun and also works across platforms. Here I’ll show you how to use them in tandem across Windows, Mac OS X and Ubuntu Linux. Please keep in mind that the actual DiffMerge and Git installation locations may differ on your system requiring a slight tweak or two to the commands below.


Mac OS X

Configuring Git to use DiffMerge in Mac OS X is probably the easiest configuration of the three platforms. After installing Git and DiffMerge, you’ll need to run the following Git configuration commands to get up and running.

git config --global merge.tool diffmerge
git config --global mergetool.diffmerge.cmd "/Applications/DiffMerge.app/Contents/MacOS/diffmerge --merge --result=\$MERGED \$LOCAL \$BASE \$REMOTE"
git config --global mergetool.keepBackup false

git config --global diff.tool diffmerge
git config --global difftool.diffmerge.cmd "/Applications/DiffMerge.app/Contents/MacOS/diffmerge \$LOCAL \$REMOTE"


Ubuntu Linux

Configuring Git to use DiffMerge on Ubuntu Linux is very similar to the Mac OS X configuration. The commands are the same here except for the DiffMerge installation location.

git config --global merge.tool diffmerge
git config --global mergetool.diffmerge.cmd "/usr/bin/diffmerge --merge --result=\$MERGED \$LOCAL \$BASE \$REMOTE"
git config --global mergetool.keepBackup false

git config --global diff.tool diffmerge
git config --global difftool.diffmerge.cmd "/usr/bin/diffmerge \$LOCAL \$REMOTE"



The windows configuration is the most difficult of the three configurations. I wouldn’t even bother trying to set this up using the Git configuration commands through the Git Bash command prompt. You’ll save yourself A LOT of time by just hacking your .gitconfig file manually to point to the external Git scripts required to launch DiffMerge. Here’s what you need to do…


1) Create a directory to hold your external Git command scripts – this can be anywhere. I use the ../cmd directory that is created when you install Git on Windows – C:\Program Files (x86)\Git\cmd.

2) Add your Git external command directory to your PATH System Environment Variable.

Right Click ‘Computer’ and choose “Properties” from the context menu.

Click “Advanced System Settings”.

Click the “Environment Variables” button to launch the necessary modal dialog.




3) Drop the following scripts into your Git external commands directory.


# place this file in the Windows Git installation directory /cmd folder
# be sure to add the ../cmd folder to the Path environment variable

# diff is called by git with 7 parameters:
# path old-file old-hex old-mode new-file new-hex new-mode

"C:/Program Files (x86)/SourceGear/DiffMerge/DiffMerge.exe" "$1" "$2" | cat



# place this file in the Windows Git installation directory /cmd folder
# be sure to add the ../cmd folder to the Path environment variable

# passing the following parameters to mergetool:
# local base remote merge_result

"C:/Program Files (x86)/SourceGear/DiffMerge/DiffMerge.exe" "$1" "$2" "$3" --result="$4" --title1="Mine" --title2="Merge" --title3="Theirs"


4) Edit your global .gitconfig file to include the necessary difftool and mergetool commands.

    tool = diffmerge
    tool = diffmerge
    keepBackup = false
[mergetool "diffmerge"]
    cmd = git-mergetool-diffmerge-wrapper.sh "$LOCAL" "$BASE" "$REMOTE" "$MERGED"
[difftool "diffmerge"]
    cmd = git-difftool-diffmerge-wrapper.sh "$LOCAL" "$REMOTE"


Launch DiffMerge

git mergetool
git difftool







Common Git Usage

06.28.2011 09:18 by kbeckman | Comments

Before you read much farther here, I just want to let you know that this post is mostly for my own personal use as a consolidation of scattered Git notes I’ve been keeping around… It’s my Git crib sheet describing some how-to’s and the why’s behind them. I’ll probably be updating this post on occasion as I find or figure out new Git goodies. Hopefully C4SC readers can find a gem or two in here.


Create a New Local Branch

The following command creates a new local branch in your Git repository. The workflow first switches to the local master branch and pulls all of the latest remote changes. The --rebase argument tells Git not to merge the remote master branch into your local master branch, but to replay all of the most recent individual remote commits on local master instead. Git will replay all of the commits in succession since your local master’s HEAD commit rather than forcing you to perform a single commit for the whole merge. The checkout -b command tells Git to create a new local branch and then check it out.

git checkout master
git pull --rebase
git checkout -b <new-branch-name>

Pull Remote Changes Locally

Most of the commands here look very similar to the example above, but we’re assuming an existing child branch here (off master) rather than needing to create one. The additional step here is that after updating master, we update the child branch as well. After switching to the child branch, calling git rebase master replays all of the commits to master (since your child branch’s HEAD commit) onto your child branch. Just as in the example before, the rebase command forces Git to avoid a single merge commit in favor of replaying all of the individual commits in master onto the child branch.

git checkout master
git pull --rebase
git checkout <child-branch>
git rebase master


Merge Child Branch Into Master (and Push It to Origin Master)

Before merging a child branch into master, you’ll want to repeat all 4 commands in “Pull Remote Changes Locally” prior to the merge to ensure you have the latest remote changes before merging any code. If you don’t do this, Git will force you to do it anyway… One more reminder – after getting all the remote changes and performing your merge, run your unit test suite locally to make sure nothing is broken. If you don’t do this, you deserve whatever hazing you get if you break the build.

A quick note here (because this is different than the last two steps)… When merging a child branch into master, since you updated your child branch by rebasing from master in the previous step “Pull Remote Changes Locally”, your child branch changes are fast-forwarded onto the master branch HEAD commit. This ensures that only the changes you performed on the child branch are committed to master just as if they had been done on master rather than the child branch. This keeps all of your local branch information from showing up in your remote repository (git push origin master). Why? I may have performed LOTS of commits and applied LOTS of refactorings to my child branch to get it ready to merge – I may have even used several local branches to accomplish the task. I don’t want to sei all of the local branch information in the remote repository. This is beneficial for the overall upkeep of the project because other developers may have local branches named the same as yours causing serious conflicts if all the local branch information appeared in the remote repository. This makes everyone’s job easier to integrate local changes when pulling remote changes.

git checkout master
git merge <child-branch>
git push origin master


Undelete a Deleted [Staged] File and Roll It Back

As far as Git is concerned, this is one of the easiest operations to perform. However, if you’re used to a nice right-click context menu option in Visual Studio or some other IDE, it might be one of the hardest to remember… In your head you’re saying “Undo Changes” or “Revert File”, but Git requires a two-step approach. The workflow here is to unstage the deleted file and then get the latest repository version by checking it out.

git reset HEAD /some-directory/file.txt
git checkout /some-directory/file.txt


Rename / Move a File

The following command is a shortcut. If you chose not to do it this way, you’ll end up with a few more calls. This prevents you from having to add the new file (along with tracking it) and remove the old file in separate commands. If you haven’t yet begun tracking the file you want to move, just remove the git mv command in favor of just mv since Git doesn’t know about it yet.

git mv <file-name> /new-directory/new-file-name



Pro Git -- Scott Chacon (ProGit.org)

Git for Subversion Users – Derrick Bailey (Code-Magazine)