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.

Upvotes: 56

Views: 11147

Answer 1

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

Use these options to git blame and git diff to filter:

• The -w option causes git to ignore changes in whitespace, so you can more easily see the real differences.
• The -M and -C options make it follow renames and copies; in the case of git blame also moving and copying of fragments of code across files.

See: explainshell.com - git diff -w -M -C

Answer 2

This question has a good solution for it. Briefly use git filter-branch.

I used for myself this code:

git filter-branch --tree-filter "git diff-tree --name-only --diff-filter=AM -r --no-commit-id \$GIT_COMMIT | grep '.*cpp\|.*h' | xargs ./emacs-script" HEAD

Which ./emacs-script is a script I wrote using emacs to change the code-style, it simply just call indent-region on each file.

This code works fine if there is not any file that deleted or removed from repository, On that situation using --ignore-unmatch may be helpful but I'm not sure.

Answer 3

You will also need a mergetool that allows agressive ignoring of whitespace. p4merge does this, and is freely downloadable.

Answer 4

I would recommend making those evolutions one step at a time, in a central Git repo (central as in "public reference for all other repositories to follow):

• indentation
• then reordering methods
• then renaming
• then ...

But not "indentation-reordering-renaming-...-one giant commit".

That way, you give to Git a reasonable chance to follow the changes across refactoring modifications.

Plus, I would not accept any new merge (pulled from other repo) which do not have applied the same refactoring before pushing their code.
If applying the format process brings any changes to the fetched code, you could reject it and ask for the remote repo to conform to the new standards first (at least by pulling from your repo before making any more push).