The OP already says that there is an “eyeball-based” review process that goes into this, and such process will have to remain in place.   I have worked with shops that did use git pre-commit filters, and usually one of two things happened:

• Version-control was end run.
• The git-filter replaced inspection ... if the code passed the filter, it was not examined further.

What did work well ... was a syntax-highlighting filter built into the text editor, in this case Eclipse.   The content of a TT2 macro-sequence was highlighted in one color.   (This much was already available.)   A new custom filter was added which flagged specific error-cases (and added a high-priority message to the editor status-line.)   This made the practice “eyeball evident” for ease of review.   But there was nothing to prevent you from committing anything you wanted to commit, anytime you wanted to commit it, and pushing those changesets to the repo.   The manual eyeball-review of all changesets (in the production or integration branches) still occurred as a mandatory part of the pre-deployment review process.   The highlighting made it considerably easier, though, and it reduced the number of erroneous commits very quickly.   No one wants to “do it wrong.”   An editor highlighting-macro gives subtle and immediate feedback, just as it does when any of us are writing source-code, CSS files, or what-have-you.