How do I run a style linter and commit changes without destroying the git blame history?

Question

Let me start by saying I've searched high and low and have not found a good answer.

If my change were only converting tabs to spaces, or running a script that did everything automatically, then this one would work: git: change styling (whitespace) without changing ownership/blame?

I want to run an arbitrary interactive cleanup, such as running a style linter then taking human steps to resolve the issues, how do I then make a commit without affecting the git blame? I see there is --reset-author, but it turns out that resets everything to the author of that one commit, not what this situation needs.

Answer 1

You can still use the general idea outlined in the linked question, but you won't be able to use git filter-branch to run it. Well, not directly. Study the filter-branch script to see how it sets each new commit it makes so that this preserves the author and committer name, email address, and time-stamp, and to see how it runs a tree-filter.

One way or another you will have to write some not-entirely-trivial code yourself, to run your style linter and then obtain the desired help. I see two obvious paths for doing this:

• Reproduce the logic of filter-branch, but in something that saves state across multiple runs (saving state in files, for instance). That way you can start it, tell it to run until it needs interaction, and have it terminate at that point. Now you can fix things up and invoke it with the "continue" option, have it run until it needs help again, and then stop again. Repeat until done.

• Write or modify a filter-branch script so that during your --tree-filter (this would be the one to use), if it encounters a situation in which it needs human help, it pauses. (Perhaps have your tree-filter read an instruction from a named pipe at this point. The instruction can be limited to just 'continue': the idea is that it doesn't actually continue until told to go ahead.)

  While it's paused, you manually enter the temporary directory containing the tree and fix it up. When that's ready, you send the "continue" instruction into the named pipe, and your tree filter then returns control to filter-branch, which goes on its way, filtering.

This second method means that you don't have to save and load the filter-branch state—the existing git filter-branch code just works as is; it just seems that somehow, the tree-filter it runs is sometimes so slow as to take minutes instead of just a few seconds.