There isn't a commonly distributed tool to do this, so you will have to write your own. I would write a Bash script that calls
indent with different parameters to create a large number of alternate versions of the original source file, then finds the "best"
diff output for each alternate version, where "best" might be simply the least number of changed lines.
My experience is that you can partition the problem if you know who wrote the original code. Programmers tend to adopt long-term formatting habits that differ from programmer to programmer.
You should expect that even in the best cases, the diffs that
indent introduces will render svn/git blame useless. This will probably force you to either adopt one specific
indent policy for all of the code and start a new repository with automatically formatted code, or else to just abandon the whole idea. A repository with several different
indent policies will probably cause more confusion and aggravation than benefit.
If you are working on new code and not just making small changes to existing code, then best practice would be to require all contributors to use a specific
astyle policy before submitting code. You could also do this automatically using hooks on svn/git commit but this can cause compile errors or even bugs in rare cases. If you are working in an organization and not running an on-line project where you are the gatekeeper, then you will need a manager with sufficient authority to enforce the policy as most programmers already know from years of experience that their own formatting is the only correct way and all other formatting is invalid.