Stop a reformatting commit ruining git blame

Does this match your situation?

• Every line in a file is attributed to one commit titled 'chore: run prettier'.
• A whitespace, tab-to-space or line-ending migration has flattened the history.
• git blame is useless for working out why a line exists.
• 'fatal: could not open object name list: .git-blame-ignore-revs'

Step-by-step fix

1. Find the commit that flattened everything

   Blame the file and look at what dominates it. Once you have the hash of the reformatting commit, everything else follows.

   step 1Copy

   git blame src/app.ts | head -20
   git log --oneline --all --grep='format\|prettier\|lint' -i -n 20
   

2. Create the ignore file

   Full 40-character hashes only — abbreviations are rejected. Comments are allowed and worth writing, because in a year nobody will remember what each hash was.

   step 2Copy

   cat > .git-blame-ignore-revs <<'EOF'
   # Migrate to Prettier across the codebase
   2b4a8d1f9c3e5a7b1d0f8e6c4a2b9d7f1e3c5a8b
   
   # Convert tabs to spaces
   9f3e1c7a5b2d8f4e6a0c9b3d7f1e5a8c2b4d6f0a
   EOF
   git add .git-blame-ignore-revs
   git commit -m "chore: ignore formatting commits in blame"
   

3. Tell Git to use it

   Set it in the repository so it applies to every blame you run there. Committing the file means teammates only need this one command, and many will get it for free from their host's web view.

   step 3Copy

   git config blame.ignoreRevsFile .git-blame-ignore-revs
   git blame src/app.ts
   

   ✅GitHub and GitLab both detect .git-blame-ignore-revs automatically in their blame views — no configuration needed there.

4. Ignore a commit without any setup

   For a one-off investigation you do not need a file at all. --ignore-rev takes a hash directly.

   step 4Copy

   git blame --ignore-rev <hash> src/app.ts
   git blame --ignore-revs-file .git-blame-ignore-revs src/app.ts
   

5. Ignore whitespace changes entirely

   Independent of the ignore file, -w tells blame to disregard whitespace-only differences. Combining it with -C and -M also follows lines through moves between files, which is where most 'who wrote this?' questions actually end up.

   step 5Copy

   git blame -w src/app.ts
   git blame -w -C -C -M src/app.ts
   git log -p --follow -- src/app.ts
   

Why this works

Blame works by walking history and asking, for each line, which commit last touched it — so a commit that rewrites every line in the repository genuinely is the last one to touch all of them. The information is not lost; it is one layer down, behind a commit that changed presentation rather than meaning. blame.ignoreRevsFile makes that distinction explicit: for the listed commits, blame attributes each line to the commit before instead. The mechanism is deliberately opt-in and stored in the repository rather than inferred, because Git cannot tell a purely cosmetic change from a real one — only the people who made it can, which is why the file is something you curate as your codebase gets reformatted.

If that didn’t work

• 'could not open object name list' means the path is wrong or the file is not committed on this branch.
• Hashes must be the full 40 characters; short ones are silently unusable.
• git log -S'<code>' finds the commit that introduced a string regardless of formatting churn.
• For a file rewritten wholesale, git log --follow -p often reads better than blame.

How to stop it happening again

• Add the hash to .git-blame-ignore-revs in the same pull request that does the reformatting.
• Keep formatting changes in their own commit, never mixed with logic.
• Adopt a formatter early and enforce it in CI so there is one flattening commit rather than many.
• Set blame.ignoreRevsFile in the repository config so nobody has to remember the flag.

Commands used in this guide

Frequently asked questions