Our project, WebGUI, a perl-based CMS, has a varied group of developers.  Most developers are consultants and contractors who make a living from customizing and developing applications for WebGUI.  Some are users who dabble in writing macros and simple sub-applications.  A few are purely volunteers.

Git seems to be good for this, as it allows each developer to set up their repository in the way that is most comfortable for them.  For example, last week I set up a pre-commit hook to run our syntax check test before allowing me to commit from my repository.  I've learned a few things since then.

All is quiet

The syntax check test runs two tests per file, one for errors, and another for warnings.  It was returning 1540 lines of input, even for a clean check.  To quiet this down, I added a redirect to dev/null to the end of my hook.

> /dev/null 2>&1

Yesterday, I thought I broke git.  Whenever I tried to commit, git would return nothing.  No warnings, no status, nothing.  It took me half an hour to figure out the problem.  I had a syntax error in some code I was trying to commit.  And since I'd redirected all output from the test to dev/null, git was telling me exactly what I told it to, nothing.  With 5 less characters in the hook, I'm much happier.

Status quo

Happy until today.  I updated my repo, did some work, and then went to commit some code, and it wouldn't let me commit.  This time, it was due to syntax problems in other people's code!  Apparently, I'm the only dev who has started using the pre-commit hook.

On the one hand, I was happy that the problems were caught early.  On the other hand, I'm strongly tempted to add small snippets of code that will write the pre-commit hook into each dev's .git directory when they start WebGUI.