I worked with a team for a while which brought in a “tidy” function, and it was very quickly a version-control train wreck:   the filter made countless “little” changes to the source-code, triggering what the VCS saw to be a massive-change commit, whereas the code had not “changed.”   The VCS wasn’t language aware, and offhand I don’t know of one that is.

The team switched to using PerlTidy as an Eclipse plug-in but only on new code, and even that really did not last long.   (The plug-in could tidy-up a highlighted block, which was nice.)   Once people got the hang of writing “tidy” code, they simply did it themselves for their new patches and so-forth.

In the name of version-control continuity, there were two three house-rules:

1. Even if it’s ugly or unsightly, leave it alone unless you are actually, meaningfully, changing something.
2. Limit the scope of your change to what needs doing to get done the job-at-hand.   Don’t make gratuitous source-changes that are not clearly related to the ticket / change-order being worked-on.
3. Don’t be clever, e.g. in the name of “efficiency.”   Just be clear.   map and grep chains, for example, were generally verboten, because that leads to tightly-coupled code that is hard to revise, and so on.   Even a “tidy-fied” version of hard-to-understand or hard-to-change code is still ... hard to understand and hard to change.   The code was meant to be easily understood “at a glance,” and that entails far more than indentation and capitalization.