I have recently been using git for local source control. It seems like a really nice system and I keep finding great new features. gitk is worth it’s weight alone. This gives you a visual browser for reviewing your source history. And the branching and merging just work as it should do.

If you don’t know much about git then have a look at the Google tech talks by Linus Torvalds and Randal Schwartz , there are some innovative online hosting websites such as github, and it also happens to already work really well with subversion using git-svn if you hav a legacy system in place.

One really great feature is that you can set up hook scripts to run when you commit changes (see the documentation here). You just need to chmod +x to make the hook script to make it executable and add the commands to call. We can then add several tasks to run on our code. Here are some examples that I may be trying out – I will post more details here:

The pre-commit hook is run just before committing our code to the repository. Here we can run several housekeeping tasks such as:

• Check for relative and local paths.
• Run astyle or indent to format our code consistantly.
• Make line endings consistant. Running dos2unix is the easiest approach.
• Run ctags to update the ctags definition.

As an aside, personally I prefer using nedit with a modified version of Peter Muyz’s renderman syntax highlighting. ctags files can be set in the language mode definition. To jump to a definition use Crtl-d. Also handy are Ctrl-y to open a highlighted header, and Ctrl-m shows you matching parentheses. There doesn’t seem to be a direct equivilant on Windows – jedit is about as close as you can get. I keep meaning to learn some more vim or xemacs, but always come back to nedit.

The pre-receive hook can be used to run any unit tests to makes sure the changes we are pushing do not break anything.

The post-update hook is run after we push our changes to the central facility repository. This is good opportunity to update initialisation and documentation. eg:

• Update the slim.ini file to include new Slim templates.
• Run any make files to rebuild compiled shaders
• Running doxygen to generate documentation.
• Mail the updates to a wiki/newsgroup/RSS feed
• Update the issue tracking system

I will add more posts when I have played with it more!

There is an example of only commiting if your code passes it’s unit test here.