Git Blame — Wrong Developer Got Flagged in Postmortem

Teams use git blame to find who introduced a bug. But blame shows the LAST person to touch a line, not the ORIGINAL author. A formatting commit, a merge conflict resolution, or a whitespace fix all overwrite the blame trail. In the worst cases, the blame finger points at the wrong developer entirely. This guide covers how to read blame accurately, how to dig past cosmetic changes to find the real origin, and the production incident where blame misattribution nearly cost an engineer their reputation.

Reading git Blame Output Correctly

git blame output has four columns per line: commit SHA, author name, timestamp, and line number with content. The SHA links to the full commit details via git show <sha>.

The most misinterpreted column is the author. If a formatting PR ran git add . && git commit -m 'Format', every line in the file now shows the formatting commit's author. The original author is buried. The -w flag (ignore whitespace) skips blame entries that only changed whitespace. The -C flag detects lines moved or copied from other files.

To trace the actual origin of a line: git log -S 'specific string' -- <file>. This searches commit contents, not blame annotations, and finds the commit that INTRODUCED the string regardless of subsequent formatting changes.

# Basic blame — who last touched each line?
git blame src/app.ts

# Blame a specific line range
git blame -L 45,60 src/app.ts

# Ignore whitespace-only changes
git blame -w src/app.ts

# Detect lines moved from other files
git blame -C -C -C src/app.ts

# Find when a specific string was introduced
git log -S 'paymentService.process' -- src/app.ts

# Trace the full history of a file (including renames)
git log --follow -p -- src/app.ts

Using git log -S and -G to Find the Real Origin

When blame points at the wrong commit, git log -S (pickaxe) searches commit contents for a specific string being added or removed. git log -S 'functionName' shows every commit where the number of occurrences of 'functionName' changed.

The `-G` flag is more powerful: it shows commits where the patch matches a regex. git log -G 'pattern' finds structural changes even if the string count didn't change.

For tracking a line through renames: git log --follow -p -- <file> follows the file across renames and shows the full diff for each commit.

# Find commits that introduced or removed a function
git log -S 'processPayment' --oneline

# Find commits matching a regex pattern
git log -G 'TODO|FIXME' --oneline

# Follow a file through renames, showing full diff
git log --follow -p -- src/legacy/payment.ts

# Combined: find when a function was first introduced
git log --diff-filter=A -S 'processPayment' --oneline

# Show blame ignoring specific commits (formatting/refactor)
echo 'a1b2c3d' > .git-blame-ignore-revs
git blame --ignore-revs-file .git-blame-ignore-revs src/app.ts