I don’t use Logseq Sync, and I just used this workflow to restore some lost content on a page.
TLDR/BLUF: rsync
a copy of your graph’s directory on the filesystem to a temporary location where we can poke around without consequences, find the commit you want your file/page/asset to be at using git
, check it out and view it, and then check it out in your real graph’s directory.
This procedure is probably written up somewhere, but I wanted to share it in case it isn’t, and see if anyone has any optimizations or improvements to it.
It’s good for one file/page/asset at a time, which is what I describe here, but you could easily omit the path to the file from the git commands, and restore the entire graph to a previous point in its history; just be careful, and always test it out first.
Workflow
Prerequisites
To do this, your desired original state of the page needs to be committed in version control for your graph.
- in Logseq, go to Settings → Version Control → Enable git auto commit, and turn it on
in your Logseq graph - Adjust the autocommit period to your liking (I use 5 minutes, but might go lower again, after today)
Find the correct version of the file
Work in a copy of your graph, initially
For a change that happened while you had autocommit enabled, you can do the following.
First, work with a copy of our Logseq graph’s directory (a git repository, now that we’ve enabled autocommit) on the filesystem, in order to prevent the risk of restoring files and then having those autocommitted before we’ve reviewed them (we do eventually want this) or making other blunders using git
incorrectly. For a graph mygraph
on the filesystem:
rsync -avP <path_to_mygraph> /tmp/restore-my-logseq-graph
# we'll leave out the bit about trailing slashes in Logseq for now
This is a full fledged git repository, with all your history.
Find the commit before the one that introduced the undesirable change
To do this, for a given file myfile
(a page, say), use git log with diffs, and follow changes only to that file:
cd /tmp/restore-my-logseq-graph/mygraph
git log --patch --follow --patch -- <path_to_myfile>
Find the commit that has the last desirable change, i.e., a commit that is before undesirable things started happening. You may want to search for “how view git diff” if you’re unfamiliar with the diff syntax.
Copy the commit hash.
Checkout the file at this commit
Run, while still in the temporary restored graph directory,
git checkout <commit_hash_you_copied> -- <path_to_myfile>
Inspect the file in a Markdown viewer
I use ReText, (clicking “Preview” once the file is open) but you can use anything, including opening the file in your favorite editor and making sure the raw Markdown is present as you desire it:
retext <path_to_myfile> # click "Preview" when it opens
vim <path_to_myfile> # look at raw Markdown or use a plugin to render
# etc
Consider opening the copied directory as a new graph in Logseq
If you really wanted to see it how Logseq renders it, you could create a new graph out of your rsync
’d graph location; you could even keep it somewhere more permanent on the filesystem, rather than in /tmp
, and repeat this whole process any time you want to restore something (starting with rsync, to update it).
Restore the file in your original Logseq graph
If all looks good in the file in your temporary restored graph directory, you’re ready to restore it in your original Logseq graph directory
cd <path_to_mygraph>
git checkout <commit_hash_you_copied> -- <path_to_myfile>
Wait the autocommit interval, and this restoration change will also now be committed and in
your history. You can view it:
git log --patch
Conclusion
Congrats, you just restored a file and saved yourself hours of work. Let me know if you have any ideas to improve a process for backup if you don’t have Logseq Sync.