Bob's Blog

As a relative newcomer to Git one of the things I've struggled most with is how to compare files from different branches. The challenge comes from the fact that, from the perspective of the file system, two branches cannot exist at the same time. When you switch from one branch to another the new branch replaces the old branch, so you cannot use a native file compare tool to compare two sets of files, as there really is only one set of files at any point in time. Now I admit that I might be totally wrong about this, and I'm sure that there are other, perhaps better, solutions to the issue, but the one that works for me currently is git difftool.

What is Git Difftool?

According to the man page for git-difftool,

git difftool is a git command that allows you to compare and edit files between revisions using common diff tools. git difftool is a frontend to git diff and accepts the same options and arguments.

I've tried using git diff in the past and, after spending years working with a wonderful tool like Subclipse's Synchronize with Repository, I just did not enjoy the output of git diff at all. Luckily, git difftool works with a file compare tool on your system, making the output much easier (for me at least) to deal with. On my system, which is OS X, because I have the Apple Developer Tools installed, when I issue the git difftool the output is sent to opendiff, which in turn uses FileMerge which is a nice, graphical file compare and merge tool. Other than installing the developer tools, which I did long before I started using Git, I didn't have to do any other setup. I honestly have no idea how easy it is to set up a graphical compare tool to work with git difftool on a Windows or Linux box, but I'm guessing it cannot be that difficult.

Using Git Difftool

To start a compare, you simply issue the git difftool command and pass it paths to two sets of files. The paths look like branchName:path. So if I wanted to compare the file ValidationFactory.cfc from the master branch to the same file in the newStuff branch, I'd type:

I'd see a prompt that says something like:

And when I hit return FileMerge would open up with both files displayed. If I want to compare an entire folder, I can just type

And then I receive that prompt for each individual file in turn.

I still don't think this is anywhere near as good as what I had with Subclipse, and I'm guessing there are ways to configure it to make it even friendlier, but for now it's much better than git diff.

There are a number of Git commands which pop open a text editor which you then use to provide information. For example, if you issue the command:

The editor will appear allowing you to type your commit message. The default editor that appears for me, on OS X, is vi which is a strange beast to work with if you've never encountered it before (which I hadn't, prior to using Git). I found a helpful cheat sheet, which allowed me to use the editor, but I still find it cumbersome. Thankfully it's a pretty simple matter to use a different text editor with Git. There are a number of ways of doing this, and I'm going to discuss two of them. To start, let's look at how Git decides what editor to use.

Which editor will Git use?

According to the man page for git-commit:

The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order).

We're going to look at changing the EDITOR environment variable and the core.editor configuration variable.

Change the EDITOR environment variable

Simply add the following line to your .bash_profile:

This will cause Git to use TextMate, and may also allow other command line tools to use it as well.

Change the core.editor configuration variable

Issue the following command:

This is useful if you only want to change the behaviour of Git, and not affect the rest of your environment.

Today I had a need to connect to and mess around with one of the Derby databases that ships with ColdFusion. I don't have RDS set up, plus I'm fairly certain that RDS does not allow you to modify data in tables, so I needed a solution. I had no idea where to start, so of course I simply Googled "derby database client tools" and one of the first links I saw was an article entitled Using SQuirreL SQL Client with Derby, by Susan Cline. I recalled that SQuirreLSQL is a client that runs on OS X, so I clicked.

Boy was I glad that I did. The article covers just about everything you need to know to get up and running with Derby on OS X, and a whole lot more, and I highly recommend reading it. If you don't feel like seeing the details, I've included a simple step-by-step guide below:

1. Install SQuirreLSQL
   1. Download SQuirreLSQL from the downloads page. I clicked the link labelled Install jars (and source) of SQuirreL 3.1 for MacOS X.
   2. Open up a terminal window and change to the folder where the downloaded jar file is located.
   3. Run the install package by typing the following command:

      java -jar squirrel-sql-3.1-MacOSX-install.jar

      where squirrel-sql-3.1-MacOSX-install.jar is the name of the file you downloaded.
   4. Tell the installer where to put the app file (I chose /Applications/SQuirreLSQL.app), and choose the plugins to install. I chose a whole bunch of plugins as I wanted to see what they do, but make sure you choose the Derby plugin.
2. Configure SQuirreLSQL to Use Derby
   1. Start SQuirreLSQL by running the app file that you just installed.
   2. Click the Drivers tab.
   3. You should see Apache Derby Embedded as one of the drivers listed. If it has a blue check mark beside it then SQuirreLSQL is ready to access Derby databases, and you can continue with Configuring SQuirreLSQL to Use Your Database, below. On the other hand, if, like me, you see a red x beside it, then you need to continue with the following steps.
   4. Select Apache Derby Embedded in the list and click the pencil icon, which allows you to edit the driver.
   5. Click the Extra Class Path tab and then click the Add button.
   6. Browse to a folder that contains the derby.jar file. It should be located in the /lib folder of your ColdFusion server. For example, on my machine it's in /Developer/CF9/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib. Select the derby.jar file and click the Choose button.
   7. Now click the List Drivers button which should populate the Class Name select box.
   8. Select org.apache.derby.jdbc.EmbeddedDriver from the Class Name select box, and click the OK button.
   9. You should be returned to the main SQuirreLSQL window and see the message

      Driver class org.apache.derby.jdbc.EmbeddedDriver successfully registered for driver definition: Apache Derby Embedded

      at the bottom of the screen. The Apache Derby Embedded driver should now have a blue check mark beside it.
3. Configuring SQuirreLSQL to Use Your Database
   1. Click on the Aliases tab.
   2. Click the blue + symbol to add an alias.
   3. Give your alias a name. I chose the name of the database, so I put cfartgallery into the Name text box.
   4. Choose Apache Derby Embedded from the Driver select box.
   5. In the URL text box, replace the text <database> with the location of your database. I went to the datasource information in the ColdFusion Administrator and copied the contents of the Database Folder text box from there. The value I used was

      /Developer/CF9/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/db/artgallery

   6. Check the Auto logon check box.
   7. Click the Test button. You should see a dialog pop up saying "Connection successful".
   8. Click the OK button. You should now be able to connect to the cfartgallery database!

Once again I just want to point out that all of this is covered by Susan Cline in her excellent guide. If by any chance she ever reads this, I'd like to thank her for this wonderful and well written resource.

I've been trying, on and off, for nearly six months to get two versions of ColdFusion, CF 8 and CF 9, running in a MultiServer install of CF with JRun on my Mac. I've read all of the documentation that is available, as well as a good number of blog posts, but I always seem to get stuck at the point of deploying my CF9 EAR into my existing copy of JRun (which was installed during the MultiServer install of CF8). Everything I've read suggests that auto-deploy should work - you just copy your exploded EAR into a folder under JRun/servers/ and JRun will deploy CF9 for you. Well, for whatever reason, that simply does not work with my setup. I also tried to manually deploy (in spite of there seeming to be zero documentation on how to do that), but still could not get my instance of CF9 to start up in JRun.

After walking through all of the steps yet again yesterday, and coming up with the same result, I asked someone who in my mind is the most knowledgeable person about this topic, particularly when it comes to OS X, Sean Corfield. We discussed the steps I had taken, and he suggested that auto-deploy with JRun can be problematic. He then suggested a solution that worked perfectly for me, so I'm going to share it with you here.

[More]

This post is a follow-up to my earlier post about Placing Config Files Under Version Control with Git and GitHub. In that post I discussed how one can use Git and GitHub to place your config files under version control (via Git), and to maintain a backup of them (via GitHub). In this post I'm going to discuss a set up that will allow another machine's config files to stay in sync with the originals. The scenario I'm discussing involves config files, but one could use this approach for any set of files that one wants to keep in sync between two machines.

[More]

Working with Git, I've become aware of the fact that there are certain config files on my machine which require customization and therefore would be nice to have under version control. These files are often referred to as dot files, or dotfiles, as their names all start with a dot. The three files that I currently have under version control are .bash_profile, .gitconfig and .gitignore. The first two of those files expect to reside in my home directory, but the way Git works, in order to place them under version control they need to reside in a folder that is also a Git repository.

For obvious reasons I don't want to make my home directory a Git repo, but there's a simple solution to this problem. Using symbolic links, a topic that I discussed in an earlier blog post, I can keep my dotfiles in a Git repo, and also continue to use them as live config files. Here is a step-by-step guide to getting your dotfiles under version control with Git:

[More]