Bits of .NET

🔀 One Wrong git checkout — . and Your Uncommitted Edits Are Gone

Meaning to discard changes in one specific file, a slightly wrong command instead runs against the whole directory – git checkout — . – silently reverting EVERY unstaged change across the entire working directory back to the last commit, including work that was never meant to be touched.

🐞 The Problem

$ git checkout -- .
# Intended: discard changes in ONE specific file
# Actual: discarded UNSTAGED changes in every file in
#          the current directory and below, silently,
#          with no confirmation prompt beforehand.

🔍 Why This Happens

"git checkout -- ." with a bare dot as the pathspec means "every
file in the current directory," not "the file I was just thinking
about" - a very easy typo to make when meaning to type a specific
filename, especially when working across multiple files and
switching context quickly. Unlike some destructive Git operations,
this one has no confirmation step and reverts unstaged changes
immediately, silently, the moment it runs.

🚨 The Hard Truth First

• If the changes were never staged (never run through git add) and never committed anywhere, Git genuinely never had a copy of that exact content saved anywhere – this specific case is usually NOT recoverable through Git itself, unlike a dropped stash or a reset commit.

✅ The Fix: Check Every Non-Git Safety Net Before Assuming Total Loss

• Check your EDITOR’s local history/undo feature first – VS Code, JetBrains IDEs, and many editors keep their own local file history independent of Git, often for exactly this kind of accident, and can recover content Git itself never tracked.
• Check for OS-level file recovery/versioning (Windows File History, macOS Time Machine, a synced OneDrive/Dropbox folder’s own version history) – any of these can hold a snapshot from moments before the checkout ran, entirely separate from Git.
• If the file WAS staged at any point before being modified further (even to a slightly older state), git fsck --unreachable can sometimes locate a dangling blob object with that staged content – worth checking, though it won’t help for changes that were never staged at all.

⚠️ Preventing This Specific Mistake Going Forward

• Commit (or at least stage) work in small, frequent increments rather than leaving large unstaged changes sitting for a long time – staged or committed content survives this exact command, unstaged content does not.
• Prefer the newer, more explicit git restore <filename> over git checkout -- <filename> for discarding changes – the separate ‘restore’ command was specifically introduced to reduce this class of ambiguous, high-blast-radius mistake.