is there a way to (temporarily) switch off mod_perl caching/variable storing?

tomgracey has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks

I have been trying to run git through apache (ie web based version control) but git is really living up to its name and refusing to cooperate. (Just finished 2 more days of tearing hair out). Now I'm wondering if there isn't some mod_perl weirdness going on.

I have found, after (very) lengthy experimentation the simplest way I can get my error is as follows:

#!/usr/bin/perl

use strict;
my @out = `cd /test/repo; git commit -m 'msg' 2>&1`;

print "Content-type: text/plain\n\n";
print "@out\n";
[download]

What I do is I set up /test/repo so it has files waiting to commit, make sure everything belongs to apache and then fire the script off in the browser.

What I am finding now is that if I run it immediately after restarting apache it works:

[master (root-commit) 4324b48] msg
  Committer: Apache <apache>
 Your name and email address were configured automatically based
 on your username and hostname. Please check that they are accurate.
 You can suppress this message by setting them explicitly:
 
     git config --global user.name "Your Name"
     git config --global user.email you@example.com
 
 After doing this, you may fix the identity used for this commit with:
 
     git commit --amend --reset-author
 
  1 file changed, 31 insertions(+)
  create mode 100644 file.txt
[download]

... but next time I try it (after deleting the .git folder etc and resetting - but not restarting apache) I get

error: unable to create temporary file: No such file or directory
 fatal: failed to write commit object
[download]

and it doesn't work from then on. I am wondering if mod_perl isnt responsible for this odd behaviour, ie trying to use a cached value somewhere the second time around. Does anyone know a way I can test this?

Otherwise, any general thoughts on what might be going on?

Back to Seekers of Perl Wisdom