Is it possible to make changes to code without changing the information reported by `git blame`?

Question

Suppose I had a git repository with code from multiple users, but some of them don’t adhere to the indentation guidelines and use spaces instead of tabs. It would be easy to change this, but by cleaning up their code, git blame becomes less useful, since then I’d be blamed for other people’s code.

I’ve seen that one can specify the commit’s author and date using the respective flags, but this solution isn’t ideal to me, since I’d have to iterate over the users and change each user’s indentation in turn. I’d also have to find out the original commit date of the changed line in order to use the --date flag.

I also know that git blame -w ignores such whitespace changes, but I’d like to make the changes transparent. I find it cumbersome to use -w whenever i blame. (And as a sidenote, I doubt that the others will remember to use the flag when extracting information from blame.) This approach will also break down if the changes aren’t related to just whitespace (e.g. exchanging single quotes with double quotes).

Is it possible to make changes to the tracked files in git without being considered the author of the changed lines and, ideally, without changing the original commit’s date?

Answer 1

I haven't tested this core git feature out yet, but regardless, in the second half of this answer, I say a very different strategy (GitLens) that I have tested well...

Git version 2.23 came out with a feature that can address your needs. You can specify a file that has a list of commits to ignore, when doing git blame.

Steps:

1. Make one or many regular commit(s) that have code-formatting changes, only.
   • As a side note: I recommend generating a commit like that, by using Prettier. (That is a tool that lets you run a command like npx prettier -w --single-quote **/* to format your files. WARNING: that particular command will likely change/improve most of the files in the folder you run it in, AND it will follow any smlinks you have in that folder (if you use smlinks) to change files in those other, liked folders. (You must install Node to use npx.))
2. Follow the directions on https://akrabat.com/ignoring-revisions-with-git-blame/ to ignore those commit(s) when doing git blame.

Optional bonus step: read the comment someone made on that article that says how to get the GitLens extension of VS Code to pay attention to the file that lists the commits to ignore. Never use git blame on a command line ever again, and just use GitLens's git history tools.

• Extra-tangental tips about GitLens:
  • Be sure to put the "gitlens.blame.ignoreWhitespace": true, setting/line in your .vscode/settings.json file. (That file is for the vscode settings for everyone working on that project.)
  • GitLens offers many nice ways to see git blame, but when I search git history, most of the time a shallow git blame that just shows me the last editor of a line isn't powerful enough for my needs. So, when I want to see the history of a particular line, across several commits, I use the left panel. Be sure to press the little button shown here (it doesn't show up till you mouse over it) to toggle from showing git history of that whole file to showing the git history for just the line your cursor is on, and to follow file renames reliably. THIS WORKS SO WELL, I DON'T EVEN NEED TO DO THE STUFF IN https://akrabat.com/ignoring-revisions-with-git-blame/ .
  • When doing the stuff mentioned in the previous bullet point, I also find that I need to use the Pin History Button a lot . I will tell you the magically efficient steps I follow to use it. I know the steps I have listed below look long, but they only take about 1 minute to do, once you know the steps. Here's the steps:
    1. Look at the file in VS Code with the GitLens extension installed. (Hopefully you are doing this already because vscode is awesome and relatively lightweight.)
    2. Place your cursor on the line you want want to know the history of.
    3. Make sure you have line history mode toggled on. (See the first screenshot.)
    4. Toggle on the Pin History Button
    5. Click on a commit, in the list of commits right there. Click on a couple, until you find the oldest one that immediately shows you, in the middle of your screen, a diff that looks good/relevant to the line you care about (usually the top commit in the list).
    6. Place your cursor on the version of the line you care about on the left side of the diff.
    7. Press the Pin History Button twice, to toggle it off, then back on.
    8. Go back to Step 5, and repeat, until you find the commit that introduced that nasty bug into your beautiful code, so you can know the author of that commit, and send them a polite note, to let them know what specific type of error they might want to especially watch out for, next time.