Git Blame & Archaeology
debt(d7/e3/b1/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate automated detection is 'no' and the signals are qualitative — non-obvious code without blame context, orphaned code, code owned by someone who left. Tools listed (git, github, gitlab) require deliberate human investigation; no automated linter or SAST will flag that git blame wasn't consulted or was misread.
Closest to 'simple parameterised fix' (e3). The quick_fix describes adding flags like -w for whitespace and using git log -S for pickaxe search — these are minor workflow adjustments rather than a one-line code patch, but they are contained, low-cost corrections to how the tool is invoked rather than multi-file refactors.
Closest to 'minimal commitment' (b1). Git blame and archaeology are investigative workflow tools, not structural code choices. Using or not using them imposes no persistent architectural tax on the codebase itself; each use is isolated and doesn't shape future maintainer decisions beyond good documentation habits.
Closest to 'notable trap' (t5). The misconception field directly names the canonical trap: developers assume git blame is for assigning fault rather than understanding context, leading to blame culture rather than learning. This is a well-documented gotcha (even the command name reinforces the wrong mental model), but experienced developers eventually learn the correct intent.
Also Known As
TL;DR
Explanation
git blame file.php shows the last commit and author for each line — useful for context on why code exists. git log -S 'string' finds commits where the string was added or removed (pickaxe search) — answers 'when was this function added?'. git log --follow -p file traces the history of a file including renames. git bisect binary-searches commit history to find the first bad commit introducing a bug. git annotate is an alias for blame with more context. Combining these tools turns git history into comprehensive documentation.
Common Misconception
Why It Matters
Common Mistakes
- git blame showing a formatting commit — use -w to ignore whitespace changes.
- Not using git bisect for regressions — manually checking 50 commits is hours; bisect finds the culprit in 6 steps.
- Assuming the blamed commit explains everything — the PR or issue linked from the commit message has more context.
- Not using git log --follow for renamed files — plain git log stops at the rename.
Code Examples
# Manual regression hunt — slow:
# Bug appeared 'sometime in the last month'
# Check commit from 30 days ago: bug present? No
# Check commit from 20 days ago: present? No
# Check commit from 10 days ago: present? Yes
# ...
# 2 hours later: found the commit# git bisect — binary search, 6 steps for 64 commits:
git bisect start
git bisect bad HEAD # Current commit has the bug
git bisect good v1.5.0 # This tag was fine
# git checks out the middle commit:
git bisect good # No bug here — move to upper half
git bisect bad # Bug here — narrow further
# ... 4 more steps
# Result: 'abc1234 is the first bad commit'
git bisect reset
# Find when a function was added:
git log -S 'processPayment' --oneline
# Show full history of a file:
git log --follow -p -- src/Payment/Gateway.php