Introduction

git blame works on lines that exist in the current file snapshot. If a line was deleted, regular blame cannot point to it directly because there is no line to annotate. The workflow is to locate the commit where the line disappeared, then inspect the parent commit where it still existed. Git provides several tools for this: pickaxe search (-S and -G), file history with rename tracking, and targeted blame on earlier revisions. Once you combine these commands, you can reliably identify who introduced and removed a deleted line.

Step 1: Find the Deletion Commit

If you remember exact text, pickaxe search is usually fastest:

git log --all -- path/to/file.py -S "critical_flag = true" -p

-S finds commits where the count of that string changes. If you need regex matching, use -G:

git log --all -- path/to/file.py -G "critical_flag\s*=\s*true" -p

Read the patch and identify the commit where the line is removed (- lines in diff).

Step 2: Blame the Parent Revision

Suppose deletion commit is abc1234. The deleted line existed in abc1234^ (its parent). Blame the relevant file revision there.

git blame abc1234^ -- path/to/file.py

If the file changed location over time, add history discovery first:

git log --follow --name-status -- path/to/file.py

Then blame the historical path at the earlier revision if needed.

Step 3: Narrow to a Line Range

For large files, annotate just the affected region.

git blame abc1234^ -L 120,150 -- path/to/file.py

If you only know function names, locate them in the parent revision first:

git show abc1234^:path/to/file.py | nl | sed -n '110,170p'

Then run ranged blame for precision.

Useful Variants for Complex Histories

For aggressive code movement, use move/copy detection:

git blame -M -C abc1234^ -- path/to/file.py

To inspect around the exact deletion patch quickly:

git show abc1234 -- path/to/file.py

Then jump backward through history with git log -p on that path until you find introduction and subsequent edits.

Practical Verification Workflow

A reliable way to avoid regressions is to validate the solution in three passes: baseline, controlled change, and repeatability check. First, capture a baseline outcome before you apply fixes. This could be a failing command, a wrong output sample, a stack trace, or a screenshot of current behavior. Second, apply one focused change and rerun exactly the same checks so you can attribute improvements to a specific edit. Third, rerun the checks multiple times or with slightly different inputs to ensure the fix is not accidental or data-specific.

A lightweight template you can adapt for most projects looks like this:

1# 1) reproduce current behavior
2./run_example.sh > before.txt
3
4# 2) apply your change
5# edit config/code based on this article
6
7# 3) verify behavior after change
8./run_example.sh > after.txt
9diff -u before.txt after.txt

If your environment involves tests, add at least one focused regression test that would fail before the fix and pass after it. This turns a one-time troubleshooting success into a durable maintenance improvement, which is especially important when teams rotate ownership or upgrade dependencies later.

Common Pitfalls

• Running git blame on HEAD and expecting deleted lines to appear.
• Using -S with slightly different spacing or quoting than the original text.
• Forgetting --follow when the file was renamed or moved.
• Blaming the deletion commit itself instead of its parent revision.
• Ignoring move/copy options (-M -C) when code was refactored across files.

Summary

To blame a deleted line, first locate the commit that removed it, then run blame on the parent revision where the line still exists. Combine git log -S/-G, git show, and range-based blame to keep the search precise. This method works reliably even in large repositories, especially when you add rename and copy detection for refactored code.