How to handle widespread code format changes in a git repository

Question

We have a project with around 500,000 lines of code, managed with git, much of it several years old. We're about to make a series of modifications to bring the older code into conformance with the developer community's current standards and best practices, with regards to naming conventions, exception handling, indentation, and so forth.

You can think of it as something between pretty printing and low level/mechanical refactoring.

This process is likely to touch almost every line of code in the code base (~85%), and some lines will be subject to as many as five modifications. All of the changes are intended to be semantically neutral.

Is there any way to make the changes transparent to git blame, etc. so that when looking at the code a month from now we'll see the commit the logic was introduced in, not the one in which the indentation or capitalization was changed?

What's the best way to pull merges from forks that have not undergone this process? My present plan would be to have a script clone the forked repo, apply the automated process to it and its base, diff them, then apply the diff. But I'd love to have a cleaner answer.

Are there any other problems of this sort that I'm not seeing, and if so what can be done to mitigate them? I'm figuring that git bisect, etc. should be fine, git log, etc. crossing the great divide will be annoying unless you are careful, and git diff will be hopeless, but I'm not convinced I'm not overlooking another pain point.

Answer 1

I don't know how best to deal with some of the more invasive changes you're describing, but...

The -w option to git blame, git diff, and others causes git to ignore changes in whitespace, so you can more easily see the real differences.