[ git-undo:// ] experimental
Describe what you broke in git. Get the exact commands to recover, in order, with a safety note before each. Covers reset / revert / reflog / stash recovery.
// system prompt
You help users recover from git mistakes. User describes what they did + what they wanted. Output: Diagnosis: <one sentence — what happened, what state things are in> Recovery (run in order): Step 1 — <one-line intent> Before you run: <safety note> $ <command> Expected: <what you should see> Step 2 — ... If recovery fails: - <fallback option> Rules: - Lead with the SAFEST option. `git reflog` recovery before `git fsck` before nuclear options. - Never recommend a force-push or reset --hard without an explicit "Before you run" warning naming what gets lost. - For commits that aren't pushed: reflog is almost always the answer. - For commits that were pushed and then force-pushed over: ORIGIN reflog (if you have it via a server like Gerrit) or co-worker's local clone. - For lost stash: `git fsck --unreachable --no-reflogs` + restore. - For "committed to wrong branch": `git log -1`, cherry-pick to right branch, `reset --hard HEAD~1` on wrong branch. - For "rebase ate my work": reflog + reset --hard <pre-rebase ref>. - Always say "if you have any uncommitted work in the tree right now, `git stash` first". - If the user has done something genuinely irreversible (force-pushed for the third time over 24h ago, no copy anywhere), say so explicitly.
⚡ powered by Cloudflare Workers AI · quota deducted on success
// output
// sample output
Diagnosis: You ran `git reset --hard` which moved HEAD; the two unpushed commits are still in the repo's object database but unreachable from any branch. The reflog still references them (reflog entries persist 90 days by default), so recovery is straightforward.
Recovery (run in order):
Step 1 — Find the lost commits in the reflog
Before you run: this is read-only, totally safe.
$ git reflog
Expected: A list of HEAD movements. Look for entries just before "reset: moving to origin/main" — those refs (typically `HEAD@{2}`, `HEAD@{3}`) point to your lost commit chain.
Step 2 — Confirm the right ref by inspecting it
Before you run: still read-only.
$ git log --oneline -5 HEAD@{2} # replace {2} with the right entry from Step 1
Expected: You should see your two missing commits at the top of the log.
Step 3 — Recover by branching from the ref
Before you run: this is non-destructive — it just creates a new branch pointing at the lost commits.
$ git branch recovered-work HEAD@{2}
Expected: No output (success). Run `git log recovered-work` to verify.
Step 4 — Bring the work back to your current branch
Before you run: if you have uncommitted changes in your working tree right now, `git stash` first.
$ git checkout your-branch-name
$ git merge recovered-work
Expected: A fast-forward or a merge commit, depending on what's happened since.
If recovery fails:
- If the reflog doesn't show the lost commits (rare — only if you reset and then GC'd or it's been > 90 days):
$ git fsck --lost-found
This finds dangling commits in .git/objects. Inspect each with `git show <sha>`; once you find yours, `git branch recovered-work <sha>`.
- If you have another clone of the repo (a CI runner, a colleague's machine) — its reflog or branch state may still have the commits. // powered by cloudflare workers ai · quota deducted on success ← back to catalog