Im my company i set-up a continuous integration test and i run the tests when someone push the code on the server.
Now i want to check that the code match with the our basic coding rules, the first rule is "run mogrify on your code!"
There is something to do this check "out the shelf"? the output of this analisys can be stored on a file or something else.
thanks
On
During a git commit, you could ask your users to setup a pre-commit hook which could run the test, and block the commit.
But you don't have a guarantee that your users actually follow that policy (or bypass it with a git commit --no-verify).
So you should rather put a pre-receive hook in your central repository (the one where all developers are pushing), in order to reject the push if you detect that your tool hasn't been properly run.
See Git Hooks.
Regarding tools, uncrustify can be set as a pre-commit hook, but that can be a bit slow. But it has been used that way before.
Alternatives are listed in this thread but seem quite obsolete.
Your idea to apply on the server side could work, as a pre-receive hook (meaning you would reject the push if you detect differences between the code pushed and the same code received and "uncrustified").
On
I would recommend setting up a jenkins server with appropiate plug-ins. This CI server would then run what ever test you like on all commits to the git; module tests, coding style enforcers, system tests etc
For code style checker you can use: For C# - http://joel.fjorden.se/static.php?page=CodeStyleEnforcer
I would suggest using a lint like tool, e.g. for ObjectC you could use oclint, but basically any coding standard verification tool that can output to either text files or to stdout - you can then use a python script, (since python is one of the default languages for hooks), or almost any thing that can parse that output, and compare it to a given benchmark then return 0 if the code is no worse than before and 1 if it is.
This can then be used as a hook, either pre-commit locally or pre-receive on the server, (or even both).
Alternatively if you are concerned about the developer having actually run a given tool you can always put a wrapper around the tool that saves, as a part of the committed code, something like an MD5 of the code at the point that the tool was last run and you can write a pre-commit/receive hook that checks that the MD5/whatever of that file matches that of the committed code.