Undoing a discard or a reset

Both are in the Recovery group of the sidebar, and both are kept for as long as Keep recovery backups in Settings says — seven days unless you change it.

A discard

Discarding changes copies them first. The backup is under Discarded Changes, one row per discard, named for the paths it took — the first three, and a count of any more — with the branch, a short hash and the time it was made.

Select the row, or choose Show Diff from the actions button at its right-hand end, and the backup opens the way a stash does: its files in the middle column, the diff of the selected one on the right, and nothing you can do to it except read it and put it back. Restore Changes in the header above the list, or Restore… on the row, asks Restore Discarded Changes and then puts everything back exactly as it was — what was staged comes back staged, what was not comes back unstaged — and the backup, no longer needed, leaves the group.

If a file has moved on since the discard and the two disagree, the restore stops on a conflict. The backup stays where it is, and the first conflicted file opens in the working copy for the usual editor; a backup that could not be restored is never deleted. Nor is there a delete action for one: it leaves Recovery when you restore it, or when it expires.

This is the difference between Innesta’s discard and git checkout -- in a terminal: the second one is genuinely final and this one is not.

A hard reset

A hard reset moves your branch to another commit and throws away everything after it. Innesta takes a restore backup before it does, so the position you were at is recoverable: it is under Hard Resets, and the row’s button is Restore Reset Backup.

A hard reset also asks for a typed confirmation rather than a button press, and previews what it would change. Of the operations with a net under them it is the one with the widest blast radius, and the friction is proportionate.

When the backups expire

They are cleared, on the schedule Settings sets, the next time the repository is opened or refreshed. Git’s own reflog does not expire on the same schedule, so a commit that a reset moved past is usually still findable there — see find a commit that has disappeared.

Uncommitted changes that were discarded are a different matter: they were never in a commit, so there is nothing in the reflog to find. Those are recoverable until the backup expires and then they are gone, which is a good argument for stashing rather than discarding anything you are less than certain about.