Recovery
Destructive Git actions in Gitwright write a recovery snapshot first. The snapshot is a copy of what the operation is about to remove, stored outside the repository in the application data directory, and it is independent of the reflog.
Snapshots are a safety net for mistakes made in this application. They are not a backup system, they expire, and they do not cover changes made in a terminal.
What produces a snapshot
| Action | What is captured |
|---|---|
| Discard a file, hunk or line selection | The content being removed: a file copy, a patch, or the staged blob |
| Hard reset | The dirty working tree before the reset |
| Force-with-lease push | The remote-tracking tip the push would overwrite |
| Drop stash (single or multi) | The stash content |
| Abort merge, rebase, cherry-pick or revert | The working tree before the reset |
If writing the snapshot fails, the destructive action does not run. There is no “continue anyway” path.
Operations that only add information — commit, stage, fetch, create a branch — do not write snapshots.
Browsing snapshots
The recovery centre lists snapshots for the open repository, newest first, with the action, time, affected paths and size. Search filters the list. Selecting a snapshot shows the detail: affected files, the patch or file content, and the available actions.
For each snapshot you can:
- Restore it into the working tree.
- Export the stored patch or file to a location you choose. Tree snapshots from an aborted operation have no single file to export, so export is disabled for them.
- Delete it.
Why a restore can refuse
Before writing, the restore compares the current file with the state recorded when the snapshot was taken. If the file changed after the snapshot — you edited it, a formatter ran, another operation touched it — the restore stops for that file and reports the conflict instead of overwriting your newer work.
The snapshot is kept in that case. You can inspect it, export it, and apply it by hand, or discard the conflicting local change and retry.
When several files are affected, the restore reports per-file results: restored, skipped because unchanged, or blocked by a conflict. A blocked restore never becomes a partial silent overwrite.
Retention
| Limit | Value |
|---|---|
| Age | 24 hours |
| Count | 200 snapshots, across all repositories opened by this installation |
| Total size | 512 MiB, across all repositories opened by this installation |
Expired snapshots are purged in the background. When the count or size limit is reached, the oldest snapshots are removed first.
Snapshot metadata lives next to the local database, not inside the repository, so git status never shows it and a clone does not carry it.
Relationship to reflog
- The reflog tracks ref movement in the repository, including commits and resets. It does not store discarded working-tree content.
- Snapshots store working-tree content. They do not recreate commits.
A hard reset is covered from both sides: the reflog can move the branch back, and the snapshot can bring back the uncommitted changes that the reset discarded.