Git Reflog
debt(d9/e3/b3/t7)
Closest to 'silent in production until users hit it' (d9). The detection_hints confirm automated=no and the code_pattern describes post-hoc emergencies (lost commits after hard reset, accidentally deleted branch). There is no tool that proactively warns you that you don't know about reflog — the gap only surfaces when a developer panics after an accidental destructive operation. The problem is silent until the damage is perceived.
Closest to 'simple parameterised fix' (e3). The quick_fix describes running `git reflog` to find the target hash, then a `git reset --hard <hash>` or `git checkout -b <branch> <hash>` — a small number of targeted commands within one local repo context. It's more than a one-liner because you must identify the right hash and then act on it, but it doesn't span multiple files or require architectural rework.
Closest to 'localised tax' (b3). The burden here is knowledge-based rather than structural: once a developer knows reflog exists, the cost is minimal. It applies to any git context but doesn't impose ongoing maintenance weight across the codebase — it's a recovery tool invoked episodically. The applies_to 'any' context raises it slightly above b1, but it imposes no persistent productivity tax.
Closest to 'serious trap' (t7). The misconception field states the canonical wrong belief: 'Deleted branches permanently lose their commits.' This contradicts how most developers reason about destructive git operations (hard reset, branch delete). The common_mistakes reinforce this — developers panic, run more harmful commands, or even run `git gc --prune=now` which actually destroys the recoverable state. This is a serious trap because the 'obvious' belief (data is gone) is wrong in a way that leads to compounding mistakes.
Also Known As
TL;DR
Explanation
The reflog records every time HEAD moves: checkout, commit, reset, merge, rebase. Entries expire after 90 days by default. git reflog shows the history with hashes — you can checkout any hash to recover lost work. This is why 'I accidentally reset --hard and lost my commits' is almost always recoverable. git reflog expire and git gc prune eventually remove entries, but the 90-day default gives a generous recovery window.
Diagram
flowchart TD
ACTION[Any HEAD movement] --> REFLOG[(Reflog entries<br/>90 day retention)]
subgraph Records
COMMIT2[git commit]
CHECKOUT2[git checkout]
RESET2[git reset]
MERGE2[git merge]
REBASE2[git rebase]
end
COMMIT2 & CHECKOUT2 & RESET2 & MERGE2 & REBASE2 --> REFLOG
subgraph Recovery
VIEW[git reflog<br/>see all positions]
FIND[Find hash before mistake]
RESTORE2[git reset --hard hash<br/>or git checkout -b recovery hash]
end
REFLOG --> VIEW --> FIND --> RESTORE2
style REFLOG fill:#6e40c9,color:#fff
style RESTORE2 fill:#238636,color:#fff
style RESET2 fill:#f85149,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Panicking and running git commands that make things worse after an accidental reset.
- Not knowing that git reset --hard is recoverable via reflog — the commits are still there.
- Running git gc --prune=now immediately after a mistake — removes the reflog entries you need for recovery.
- Not using reflog to understand what happened before attempting recovery.
Code Examples
# Accidental hard reset:
git reset --hard HEAD~5 # 'I meant HEAD~1!'
# 5 commits appear lost
# Panicked response:
git gc --prune=now # DO NOT RUN — permanently deletes the commits# Recovery via reflog:
git reflog
# Shows:
# abc1234 HEAD@{0}: reset: moving to HEAD~5 ← the mistake
# def5678 HEAD@{1}: commit: feat: add payment webhook ← lost commit
# ...
# Recover:
git reset --hard def5678 # Go back to before the mistake
# Or:
git checkout -b recovery-branch def5678 # Recover to a new branch