Gwik's corner

As a lot of people, I think, I have different database.yml file according to git branch I'm working on. I was constantly switching it manually until I discovered that git has more hooks that I thought.

I set up a post-checkout hooks script to automagically switch my database.yml when checking out a branch.

It is a simple script that recover the branch name a do a symlink.

if i checkout branch master it will look for a file named config/database.master.yml and create a symlink to config/database.yml

here it is :

#! /bin/sh
#
# .git/hooks/post-checkout

BRANCH=`git symbolic-ref HEAD 2> /dev/null | sed -e 's/^.*\///'`
GITPATH="`git rev-parse --git-dir 2>/dev/null`/.."

if [ "$BRANCH" == "" ]; then
        echo "no branch name. do nothing"
        exit 0
fi

if [ -f "$GITPATH/config/database.yml" ] && [ ! -L "$GITPATH/config/database.yml" ]; then
        echo "database.yml exists and not a symlink. do nothing."
        exit 0
fi

echo "look for $GITPATH/config/database.$BRANCH.yml"

if [ -f "$GITPATH/config/database.$BRANCH.yml" ]; then
        echo "switch database configuration file to config/database.$BRANCH.yml"
        rm -f "$GITPATH/config/database.yml";
        ln -s "$GITPATH/config/database.$BRANCH.yml" \
        "$GITPATH/config/database.yml"
fi
 

or on Pastie

Working for a new client on a Rails project, I decided to give a shot at Git.

I’m working with an other developer who holds the svn repository. He is the only person allowed to commit to the trunk and I have to commit to my own branch. At first, this doesn’t seemed to be a problem. But there is a lot of files modified every day on the trunk and I’m constantly merging from the trunk to keep my branch up to date. Git seems to have some nice features that could help me to avoid those constant merges.

I writing this article while installing git so I don’t already know if it is the solution to my troubles. I just read this article and it convinced me to give git a try.

I have to mention that I never worked with git before so I will discover git with this project and we’ll see if it’s reasonable. I heard about git on rubyinside blog a few weeks ago.

So, as I’m on leopard, the easiest way (for me) to build git is macports so let’s do it.

sudo port install git-core +svn

This installs all git git-svn and gitk. All ran smoothly for me. If it fails try this install tutorial for leopard.

Now it’s installed properly I need to build my git project from subversion repository

daiquiri% git svn init https://repos.../trunk
Initialized empty Git repository in .git/

It doesn’t checkout the sources so let’s check this previously mentioned article to see what I do next.

svn info https://repos.../trunk

git-svn fetch -r3741
.
.
...The checkout happens...
.
.
r3741 = b444a88efc7248dfdd5f96a7dd7e36165a0f3ed6 (git-svn)
Checking 4130 files out...
 100% (4130/4130) done
Checked out HEAD:
  https://82.240.32.108/svn/eco-sys/trunk r3741

It seems all went ok and that my git project is ready to go.

I little config seems to make things a little prettier. I took this from here

git config --global user.name "Antonin Amand"
git config --global user.email "aamand@gwikzone.org"
git config --global color.status auto
git config --global color.diff auto                                             
git config --global color.diff auto
git config --global color.branch auto
git config --global merge.tool opendiff
git config --global core.excludesfile ~/.gitignore
echo ".DS_Store" >> ~/.gitignore
cat > ~/.gitk <<EOF
set mainfont {Monaco 10}
set textfont {Monaco 10}
set uifont {Monaco 10}
EOF

I will know do some changes in the configuration to get the working on my mac. I understood that the best practice is to create a new branch.

git checkout -b localconfig HEAD

This creates a new branch a switch in it immediatly.

git add mymodifiedfile
git add ...
git commit

git commit -a

Now I’ve seen that the other developer add update a lot of files in the trunk. So I will try to update my git branch.

git svn rebase

This first revert your repository before my modifications update from subversion and apply again my commit. All went nicely. Notice that it is extremely more powerfull that trying to apply the update directly on the modified sources.

Now I want to commit to the remote svn, but the other developer don’t allow me to commit to the trunk. I will create a patch with git, create a new branch in the subversion repository from the trunk, apply the patch and then ask for the developer to merge changes from the new branch to the trunk.

git format-patch remotes/git-svn

Then I create the branch into the subversion repository and checkout.

svn copy http://repos/trunch http://repos/branches/merge-branch
svn checkout http://repos/branches/merge-branch
cd merge-branch

Now I need to apply the patch.

patch -p1 < /path/to/thepatch

svn commit

Now I just have to send an email to the other developer.

With this first shot, I am conviced that git will improve my merging process and be a lot more flexible that SVN.

Now that I will play a lot with patches, next time I’ll probably take a look at StGIT (Stacked Git), patch management utility.