# Undo and recovery

Understand checkpoints, recovery conflicts, and the limits of Undo Push.

## Checkpoints and retention

Before an eligible operation, GitLode saves local checkpoints of staged, unstaged, and untracked data. Recovery preserves staged and unstaged changes separately, including file modes and symbolic links.

Eligible operations include commits, amendments, merges, pulls, rebases, cherry-picks, reverts, branch changes, tags, checkouts, and resets. Undo history lasts 30 days and survives restarts. Active or unresolved recovery records are retained beyond normal expiry.

Staging, discard, and stash actions do not create checkpoint Undo entries. Activity records are not all undoable. Discarding only untracked files moves them to the Trash without a journal entry.

## State checks and newer work

Before restoration, GitLode checks the current commit (HEAD) and affected branches against the recorded state. External branch movement can make an operation ineligible for recovery.

Newer working changes are reapplied during recovery. If they conflict, resolve them and choose Continue Recovery in Activity. Abort Recovery restores the state captured before recovery began. New recorded repository changes remain blocked while recovery is unresolved.

Eligible interrupted operations can have Restore Checkpoint in Activity. Confirm it to start restoration. An uncertain push has Check Remote State.

Redo restores the most recently undone eligible operation. A new completed or conflicted recorded operation clears redo history; fetching does not.

## Undo Push

Undo Push restores the recorded remote reference with an exact force-with-lease check. It fails if the remote branch changed after the push or its destination configuration changed. Undoing a newly published branch deletes that remote branch. Redo Push also checks the expected remote state.

Remote restoration cannot reverse CI jobs, deployments, or other clones. See [Undo an operation](https://gitlode.com/docs/undo-an-operation) for the controls.