Sounds like you're using it wrong. The autoformatter is for the whole repo, not for individual contributors. The point is that the whole repo has the same style, so you should only ever get diffs on the lines that were changed or the first time you run the autoformatter on the repo (and then you shouldn't be making manual changes that will be hidden amid the autoformatter noise).
Most larger orgs/projects aren't going to be willing to reformat all the code in their repo in one big bang. Regardless of what promises the tool claims to make, you need to be concerned about behavior changes or breakages, and most projects don't have high enough test coverage to cover everything. Depending on the size of your repo, it might not even be technically possible to make this change all at once. It's also much harder to get organizational buy-in on "let's change all existing code in one swoop" vs. "let's require all new code changes to be formatted using this tool".
As I mentioned above, formatting only the diffs also removes most of the pain of any changes to the formatting tool itself that aren't diff-stable.
I shouldn’t have said repo, but rather some agreed upon unit of code. It could be a single package or file as long as all contributors touching that file adhere. You should not use black for any unit of code that you can’t get buy-in on. Black is a technical tool; it doesn’t solve political problems.
Black verifies that the abstract syntax trees of the original and reformatted code are identical. There is practically zero chance of breaking changes.
