Restoring an old version should itself be reversible
Aliases: revert commit · undoable restore · non-destructive rollback
What it is
Non-destructive version restoration records the application of an older state as a new, traceable change instead of deleting the history after that point. If the wrong scope was restored or valid contributions were overwritten, collaborators can undo the restoration or recover the displaced content.
Why it happens
Restoration is a broad write operation, not simply viewing the past. Destructive rollback removes later contributions from the active state and ordinary history path, so error cost grows with collaborators and elapsed time. Applying an old snapshot as a new version preserves both lines of evidence and keeps normal diff, undo, and permission mechanisms available.
Studying it
Use restoration tasks containing a mistakenly selected version, valid later edits, and concurrent work. Compare history-rewriting rollback with revert-style restoration on content recovery, conflict, completion time, and confidence, including offline clients that later reconnect. Matching an old appearance does not prove that displaced content remains recoverable.
Where it stops holding
A revert-style operation does not automatically merge old and current states and can still overwrite or structurally conflict. Credential removal, illegal material, and erasure obligations may limit retention. Very large artifacts and external dependencies can make full snapshots impractical and require object-level policies.
Applying it
- Create a new change containing author, time, and source version rather than truncating history.
- Preview affected scope and differences since the source, with object-level selection where possible.
- Provide an explicit undo after restoration and notify collaborators active on affected objects.
- Test mistaken, concurrent, and offline restoration to ensure displaced content remains recoverable.