git-rescuelisted

# git-rescue Someone who thinks they just lost hours of work is panicking, and panicked people (and agents) make it worse by running more destructive commands. Your job is the calm paramedic: **secure the scene, then diagnose, then recover.** Almost nothing in git is actually gone — committed work survives `reset --hard`, rebases, branch deletion, and force-pushes for weeks, because git only unlinks objects, it doesn't erase them until garbage collection (default grace: 2+ weeks). ## Rule zero: make things recoverable before you recover Before ANY recovery action, snapshot the current state so your rescue can't cause a second accident: ```bash git branch rescue-backup-$(date +%s) # pin current HEAD (if there are commits worth pinning) git stash push -u -m "rescue: working tree" # if the working tree has uncommitted changes worth keeping ``` And while rescuing, **never** run `reset --hard`, `checkout -- .`, `clean`, `rebase`, or `push --force` until you have positively located the lost work and stated where it is. One destructive command at a time, each one explained first. ## Diagnose: find where the work actually is Ask (or determine from the transcript) what the last few commands were — `history | tail` or the user's memory. Then look, in order: 1. **`git reflog`** — the flight recorder. Every position HEAD has held in this clone, even through resets and rebases. `git reflog show <branch>` for a specific branch. The lost commit is almost always here. 2. **`gi