It's really not that hard. I've been through it on big projects with extensive history and multiple sync'd outside projects with internal patches and the whole 9 yards.
Start with what you own. If you don't own it, leave it be. Do all files in one big patchset. That'll be the point in time where stuff before and after won't diff very nicely, It sucks, but a year from now, it won't really matter.
Include a per-commit check. That way, no new problems get introduced.
Include the header. One does HAVE to use vim or emacs, but the mode lines I supplied work with those two. If your group has another common editor, add its mode lines if it supports it. It's just a helpful extra, and is safely ignored by other editors. And if none of you use vim or emacs, disregard those lines.
If someone has a branch that was cut prior to the big reformatting patch, they'll have to deal with it at merge, or rebranch or rebase. Sucks, but it's a one time thing.
The alternative sucks more - having code with mixed standards. How do multiple groups deal with that? Your patches are going to be even worse! Someone uses their editor to indent a block or copy/paste it, and all those mixed tables and spaces go to whatever they're using, causing all lines to diff poorly, instead of just the little pieces they touched. It's awful, as you noted.
Your specific problem you referenced was users that were using an outdated 6 year old .vimrc that had been mailed around, and it caused problems with your code because of the difference in coding standards. ADDING THE MODE LINE FIXES THAT!
The rest of it sounds like you just don't want to be bothered to clean up the problem, and just want to complain and blame others. It's trivial to fix. It comes with a small cost (one time giant ugly patchset), but it's easy. And you don't need that one time giant patch.. you could let them be fixed as changes are made, but I wouldn't recommend that as every future patchset will be more complicated than it needs to be. Just get it all out of the way in one go and move on.
For integration with external code/repositories, work within the standard of the governing body. If they have a well defined standard, you can even add the pre-commit checks to your personal repository if you want. In general, this doesn't matter as much as the above, cause either your guys are behaving well and working with the external group, or they're not - manage accordingly.