When Git Blame Becomes a “Liar”
It’s 2 AM, and the production server is hitting a logic error in the payment module. I’m staring at the screen, trying to find out who last modified the discount calculation logic. I type the familiar command: git blame src/services/payment.js.
The result is incredibly frustrating. All 200 lines of code in the file display… my own name. The commit message simply reads: “chore: run prettier for the whole project”.
Last week, I ran Prettier to clean up the project. Unintentionally, this action “overwrote” my name onto every line of code. It obscured the actual authors of critical logic from two years ago. I spent another 30 minutes digging through git log -p just to find the original commit. If your project has thousands of files, this is a total productivity disaster.
Fortunately, Git has a fantastic feature to handle this noise: --ignore-rev.
3 Ways to Clean Up Git Blame History
When tools like Prettier, Black (Python), or linters automatically change formatting, code history gets cluttered. Here are the methods I’ve tried to restore the integrity of git blame.
1. Manual Tracing Using the ^ Symbol
The simplest way is to ask Git to blame at the point just before the formatting commit occurred:
bash
git blame <commit-hash>^ -- <file-path>Pros: Works instantly, no setup required.
Cons: Only effective if the file has been formatted once. If the file has gone through 5-6 rounds of code cleanup, manual “leapfrogging” becomes exhausting.
2. Ignoring Specific Commits via Command Line Arguments
You can directly specify the hash you want Git to ignore:
bash
git blame --ignore-rev <commit-hash> <file-path>Pros: Convenient for a quick check on a specific piece of code.
Cons: No one remembers those long, cumbersome hashes. More importantly, your colleagues don’t benefit from this.
3. Using the .git-blame-ignore-revs File (Recommended)
This is the most professional approach. We create a “blacklist” of commits that only contain formatting changes and tell Git to ignore them permanently.
Why You Should Use a Configuration File for the Whole Team?
Working on long-term legacy projects, I realized that storing the ignore list in the repo provides huge benefits:
- Consistent Data: Every team member sees the same original author when tracing code.
- Platform Support: GitHub and GitLab already support reading this file to display accurate blame directly in the browser.
- Easy Maintenance: When a major refactor occurs, you just need to add one hash to the file, and you’re done.
It’s like creating a smart filter for project history. It helps protect the “historical truth” of the code, avoiding unnecessary misunderstandings when assigning responsibility or finding the person who holds the context.
Detailed Implementation Steps
Step 1: Find the Hashes of Formatting Commits
Filter out code cleanup commits using the log command. For example:
bash
git log --oneline --grep="prettier"Suppose you find two hashes: a1b2c3d4 and e5f6g7h8.
Step 2: Create the .git-blame-ignore-revs File
Create this file in the project’s root directory. The file content should look like this:
# Reformat entire project using Prettier v2.0
a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q
# Fix indentation (linting)
e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19tPro tip: Use the full hash (40 characters) to ensure absolute accuracy.
Step 3: Activate the Git Configuration
You need to inform Git of the existence of this file using the command:
bash
git config blame.ignoreRevsFile .git-blame-ignore-revsTo apply this to all projects on your local machine, just add the --global flag. However, since each project usually has a different list of commits, local configuration is best.
Step 4: Share with Your Colleagues
Commit the .git-blame-ignore-revs file to the repo. To ensure everyone doesn’t have to manually type the config command, you can add it to a post-install script in package.json or use a Husky hook. This way, anyone who clones the project will have the correct blame filter.
Real-world Results
Try running the blame command again for the original payment.js file:
bash
git blame src/services/payment.jsNow, Git will automatically “look through” the Prettier commits. The name of the colleague who wrote the logic back in 2022 will reappear. On the GitHub interface, you will also see a notification: “Ignoring revisions listed in .git-blame-ignore-revs”.
Important Note: When NOT to Ignore?
With great power comes great responsibility. I only add commits that are purely formatting to the ignore list.
If a commit both reformats code and happens to fix a small bug, absolutely do not ignore it. If you ignore that commit, the trace of the bug fix disappears. This leads you back to an older author—someone who knows nothing about the most recent change.
My experience is: Always separate formatting commits from logic commits. Never mix them. If you’ve already combined them, accept keeping that commit in the history instead of trying to hide it with ignore-rev.
Summary of the Process
- Get the hashes of commits cluttering the history.
- Save them to the
.git-blame-ignore-revsfile. - Run the
git configcommand to activate the filter. - Commit and push the file to sync for the whole team.
This trick will make your late-night debugging sessions much less stressful. You’ll find the right person to ask instead of getting frustrated by mindless code changes from linter tools.
