What closes the window for recovering unreachable commits in Git, and how do you keep it open?

## Unreachable is a state, not a deletion When a reset, a rebase, a branch deletion, or a dropped stash removes the last ref pointing at a commit, the commit becomes *unreachable*. It is still a file (or a pack entry) in `.git/objects` and can be resurrected by pointing any ref at it. Recovery is therefore a race between you and garbage collection. ## What garbage collection does `git gc` performs housekeeping: it packs loose objects, packs refs, expires reflog entries, and prunes unreachable objects. Two of those steps are what close the recovery window. **Reflog expiry.** Reflog entries are themselves roots for reachability — a commit named by a reflog entry is not pruned. gc expires those entries on a schedule governed by two settings: `gc.reflogExpire` for entries whose commits are still reachable, and `gc.reflogExpireUnreachable` for entries pointing at commits that are no longer reachable from any ref. The stock defaults are generous — on the order of ninety days and thirty days respectively — which is exactly why "just check the reflog" works so reliably in practice. `git reflog expire` is the command that does this on demand. **Pruning.** Once nothing points at an object, gc will remove it, but only after a grace period controlled by `gc.pruneExpire`, whose default is a couple of weeks. The grace period is not politeness; it exists so that a concurrent process which has just written an object but not yet referenced it does not have that object deleted underneath it. ## Automatic runs You rarely type `git gc`. Many commands — commit, merge, rebase, fetch, am — invoke `git gc --auto`, which does nothing unless the repository has accumulated more loose objects or packs than `gc.auto` and `gc.autoPackLimit` allow. This matters because it means the window can close while you are still poking around: continuing to work in a repository where you have lost commits is itself a risk. ## Commands that close the window immediately - `git gc --prune=now` — prunes unreachable objects with no grace period. - `git prune --expire=now` — the plumbing version, same effect. - `git reflog expire --expire=now --all` and `--expire-unreachable=now --all` — throws away the reflog entries that were keeping commits alive, after which the next prune removes the objects. - `git stash clear` — drops all stash reflog entries at once, making every stashed commit unreachable. These appear in "speed up your repo" blog recipes and in cleanup scripts, which is precisely why an engineer who has just lost work should not be running someone's optimisation snippet. ## The first-response routine 1. Stop. Do not keep committing, fetching, or rebasing in that repository — each command can trigger automatic housekeeping. 2. `git config gc.auto 0` in that repository to suppress automatic runs while you investigate. 3. If the work is genuinely valuable, copy the whole `.git` directory (or the working copy) somewhere safe first, so that a mistaken recovery command cannot make the situation worse. A copy is cheap; a second failed recovery attempt is not. 4. Now do the forensics — reflog first, then fsck — and anchor whatever you find with a branch or tag straight away. 5. Undo the `gc.auto` change when you are done. ## Why anchoring immediately matters Finding a hash is not recovery. Until a ref points at the commit, it remains unreachable and still on the clock. `git branch rescue <hash>` takes a second and converts a race into a settled outcome. ## The strategic view The window exists because Git's data model separates object storage from reachability, and it is deliberately generous. But a window measured in weeks is still a window, and repositories that run aggressive maintenance, or clones that are recreated frequently, have effectively no window at all. The durable answer is not to depend on it: push topic branches, make WIP commits, and treat the reflog and prune grace period as a safety net for accidents rather than as a backup strategy.