Brew, git 1.8.0 & "-bash: __git_ps1: command not found"

I updated my machine this past weekend. This included everything from Mountain Lion to Homebrew (including all formulas).

As part of this update I moved from git 1.7.2.x to 1.8.0. After I did so and launched a new terminal I started seeing this fun error

-bash: __git_ps1: command not found

I checked the git 1.8.0 release notes but could not see any mention of a change to the prompt scripts. After much research (and gnashing of teeth) I discovered that the git shell commands that were responsible for making that nice prompt were moved from contrib/completion/git-completion.bash into a separate file contrib/completion/git-prompt.sh

To fix it I added the following line to my ~/.bash_profile above where I defined my prompt

source /usr/local/etc/bash_completion.d/git-prompt.sh

Where /usr/local/etc/bash_completion.d is where brew puts the completion scripts it installs.

I am no bash guru so I will not advocate that this is the best way to fix this problem.If you are a bash guru and know a better way please comment so we can all learn something.

Prefix Git Commit Message using Hooks

My team uses Chiliproject to manage our user stories. We have a team agreement to ensure that each commit message into our git repository is prefixed with the issue ID that the commit is related to. In addition to this we have a branch naming convention that also identifies the issue that branch is supposed to address. For example, a branch name could be, "rm-3454-customer-defect" and (hopefully) all commit messages will be prefixed with "RM #3454". Chiliproject has some nice little features with linking and styling when the "#4233" pattern is found. However, it can be fickle. Ff you forget to put in a space, for example, "RM#3432" none of it will work.

Making sure this formatting is correct can be a real pain in the a**. Therefore, I took it upon myself to simplify things. The script below uses our branch naming convention to automatically prefix any commit message using the git "commit-msg" hook.

Loading ....

Put this code in the ".git/hooks/commit-msg" file at the root of your repository, make it executable and you are ready to rumble (of course, this will only work if using ruby).

ActiveRecord 3 based Rubygem

At our company we had to integrate with a legacy database system. To manage it we created a nice little gem to handle it. Basically the gem was just a collection of ActiveRecord models, nicely namespaced, so that we could include it in any application that made have needed access to that db.  Code using the gem set it up as you would expect (in a Rails app we used a custom db connection in the database.yml):

require 'legacy_database'
LegacyDatabase::Base.establish_connection(...)

This functioned great for many years and versions of ActiveRecord.

Jump forward to today, we have another separate database we need to connect to. Naturally, after the success of the previous gem we decided to create a new gem using the existing pattern, but this time we are going to use the new and fancy ActiveRecord 3 and its nice new Arel syntax. 

We started building the gem and immediately ran into a blocker.  Using the same code as above, as soon as the require was executed we get an ActiveRecord::ConnectionNotEstablished error.  Nuts!

require 'special_database' # <= raises ActiveRecord::ConnectionNotEstablished
SpecialDatabase::Base.establish_connection(...)

The backtrace showed us that when the gem was being loaded when it hits the first scope call Arel attempts to connect to the database.  Why?  I am not sure and I haven't had time to dig around to find out if it is even possible to fix. Its a classic chicken/egg situation. You can't initialize the connection until you load the gem and you can't load the gem without initializing the connection.

In our situation we aren't using the gem in concert with any other ActiveRecord connections so we are able to use ActiveRecord::Base to establish the connection.

require 'activerecord'
ActiveRecord::Base.establish_connection(...)

require 'special_database'
SpecialDatabase::Foo.find(1)  # It work's

I really don't like it, but so far its our only option. Got a better solutions I'd be happy to hear it.