Undoing things

Sooner or later you will want to take something back: an edit you should not have made, a commit that went wrong, a file you deleted by mistake. In Synck, undoing a committed change always means adding a new commit. History only grows, so you can always see what happened, including the undo.

Uncommitted changes are different. They exist only in your folder, and some of the commands on this page discard them for good. Those commands are marked.

Choosing the right tool

You want to…	Use	Changes history?	Discards work?
Look at an old version without changing anything	export, export-tree	No	No
Throw away uncommitted edits to one file	restore PATH	No	Yes
Throw away all uncommitted changes	restore-tree	No	Yes
Make a file’s content match an older version again	restore PATH --item-seq N, then commit	Adds a commit	Yes, for that file
Reverse a commit you already made	revert REVISION	Adds a commit	No
Get a deleted item back	recover PATH	Adds a commit	No

Look without touching

The safest way to get at an old version is to copy it out. Nothing in your working tree changes, and nothing is added to history:

$ synck export meetings/standup.txt ../first-version.txt --item-seq 2
exported meetings/standup.txt to ../first-version.txt
$ synck export-tree HEAD~1 ../notes-before-move
exported HEAD~1 to ../notes-before-move

export writes one file, either at its latest committed content or at the version you select with --item-seq (see A file’s versions). export-tree writes the whole tree, or one folder with --folder, as it was at a commit. Destinations must not exist, so an export can never overwrite your work. When in doubt, export first.

Discard uncommitted edits to a file

synck restore replaces a file in your working tree with its last committed content. Your uncommitted edits to that file are lost.

$ synck status
M meetings/standup.txt
$ synck restore meetings/standup.txt
restored meetings/standup.txt
$ synck status
nothing to commit, working tree clean

Discard all uncommitted changes

synck restore-tree puts the entire working tree back to the last commit. Every uncommitted change is lost. Edited files are restored, deleted files come back, moved files return to their places, and new files that Synck would have tracked are deleted:

$ synck status
A new.txt
M tasks.txt
$ synck restore-tree
restored working tree
$ synck status
nothing to commit, working tree clean

new.txt was never committed, so it is now gone for good. Ignored files are left alone. If you are not sure you want to lose something, commit it or copy it somewhere else first.

Bring back an older version of a file

To make a file’s content match an earlier version again, restore that version into your working tree, check it, and commit:

$ synck restore meetings/standup.txt --item-seq 2
restored meetings/standup.txt
$ synck diff
--- a/meetings/standup.txt
+++ b/meetings/standup.txt
@@ -1 +1 @@
-Meet at 11.
+Meet at 10.
$ synck commit -m "Go back to the original meeting time"

The file keeps its identity, and its history now shows the change back. The version you replaced is still in history if you change your mind again.

Reverse a commit

synck revert adds a new commit that does the opposite of an earlier one. It reverses the commit’s edits, deletions, moves and additions:

$ synck revert HEAD -m "Undo second rewrite"
committed sha256:70c62217bdcd12d51060439434fed201ff9d1362b7b48b1ff3a6fda9eb2d8417
$ synck log -n 1
8 | 2026-10-25 20:45 +01:00 | Alex | 1 change | Undo second rewrite
    M tasks.txt

Both the original commit and its reversal stay in the log. That is the point: anyone reading the history can see that a change was made and later withdrawn.

Revert needs a clean working tree, so commit or discard your current changes first. It is careful about later work. A later change to a different aspect of the same item is kept: reverting an old edit to a file keeps a later rename of that file, and the other way round. But if a later commit changed the same thing again, such as the same file’s content, Synck refuses rather than guess how to combine the two:

$ synck revert HEAD~1 -m "Undo first rewrite"
synck: cannot revert because later history overlaps item 01a17498-88d9-7d31-a9ae-dca2d67d0ad3

In that case, revert the later commits first, newest to oldest, or restore the content you want with restore --item-seq and commit it.

Recover a deleted item

Committed deletions go to the repository’s trash. synck deleted lists them and synck recover brings an item back under its original identity:

$ synck deleted
01a17498-6fec-7dc2-9fd6-ff8463051d65 FOLDER 9 sha256:e2a5e2d7…1fd21e 2026-10-25T19:45:22.264487990+00:00 proposal
...
$ synck recover proposal -m "Bring the proposal back"
committed sha256:0de0e0159cd862b6b45832738781c53d5d1277843b11a1acf3fa84ebaf8d84b0

See Moving, renaming and deleting for details.

What cannot be undone

Because history is append-only, some things are permanent:

• You cannot remove something from history. Committing a file, then deleting it, still leaves every version in the repository. If you commit a password or personal data by mistake, the only complete remedy is to stop using that repository and its copies, and start a new one without it.
• You cannot edit a commit. There is no amend. If a message is wrong, the next commit’s message can say so.
• Discarded uncommitted work is gone. restore and restore-tree do not keep a copy of what they replace.
• Named-version changes are not reverted. revert reverses changes to files and folders. Removing a named version label is permanent.

These limits are the other side of Synck’s main guarantee: once a change is accepted, nobody can quietly alter or remove it.