If the files are automatically generated, and they can be generated anywhere (implicit in your desire to build them in the Git pre-commit hook) then you shouldn't be putting them under source control in the first place. You should only control source files -- generated files should be generated as part of the build scripts.
The only reason to put a generated file under source control is when it requires unique/privileged resources to generate (such as a licensed program) or it requires a significant amount of time to generate.
Added
From http://www.kernel.org/pub/software/scm/git/docs/githooks.html :
pre-commit This hook is invoked by git
commit, and can be bypassed with
--no-verify option. It takes no parameter, and is invoked before
obtaining the proposed commit log
message and making a commit. Exiting
with non-zero status from this script
causes the git commit to abort.
The default pre-commit hook, when
enabled, catches introduction of lines
with trailing whitespaces and aborts
the commit when such a line is found.
All the git commit hooks are invoked
with the environment variable
GIT_EDITOR=: if the command will not
bring up an editor to modify the
commit message.
The intent of the pre-commit hook is to be a pass-fail check on the state of the workspace and the contents of the commit, prior to making the commit. Attempting to change the contents of the commit won't work.
My recommendation would be add two steps to your build scripts: (1) a step that will build all of the out-of-date files that needs to be generated (and adds them to the workspace), and (2) a step that will check to ensure that all of the generated files are up-to-date, and return a non-zero status code. Your Git pre-commit hook should run the second step. Your developers should be trained to run the first step as necessary.