I think I’m (sadly) done with @logseq. It corrupted some data again and when I went to pull the stuff from git I figured it corrupted the .git/config even earlier than that. So now I have to pull the correct content from an old windows backup, ffs. What if I didn’t have a full disk backup?
I like the idea of block references, I love the query engine and the simple UI. But data safety comes first, really. Logseq is a forever beta at this point.
I really like the concepts behind the logseq db version but @obsidian doesn’t fuck with my data and you can see good iterative progress of its development. Yeah, it’s not opensource. It’s open data format, though, something logseq db will have to figure out eventually anyway.
@farcaller @logseq I know this doesn’t change the fact that the data got corrupted - but can’t you roll back to a previous git commit to restore instead of needing a separate backup?
@mroma @logseq so this is how my git config looks. Why? I don’t know. It happens from time to time and I know logseq tries to write that file.
Now, when that file is corrupted, you’ll get a notification in logseq UI that it’s git autocommit cannot run. So you go and fix the config.
That is, if you notice the notification. My config got corrupted silently 3 weeks ago and that was the last time logseq did the autocommit, too. So yeah, you can roll to the previous good state if you have git history, but logseq can get you into a spot where you don’t have any history.
Previously I’d keep logseq in Synology Drive, too, which offered me a point-in-time backup (technically a one-way sync with history, in my case). Since I migrated to a home-made NAS I couldn’t find a replacement (I don’t really need one with a 40G fiber to my storage, I just access files right on the NAS), so the only place that still had PINT snapshots was my windows backup.