Hacker News new | past | comments | ask | show | jobs | submit login

Same here about fossil. After prolonged exposure to fossil, i tend to get the jitters when I work with git - to the extent that git repos I work with are mirrored into fossil for safe keeping.

From their docs:

> Fossil stores state information in SQLite database files [...] updates are atomic, so even in the event of a system crashes or power failure the repository content is protected.

This is actually a huge improvement over git in terms of data safety.

How so? Filesystem operations are (or can be) atomic too.

Git operations are not atomic, though. This is a huge implementation flaw, if not design flaw.

I had it several times that my laptop (or a VM) crashed during or short after a git commit, before it was fully written from cache to disk. The reasons vary, sometimes the VM disk was full, or some tests ran parallel to the commit that consumed too much RAM.

This doesn't happen often, but every few months. Meanwhile I "solved" this issue by making sure that the system is never in any form "stressed" while I work with Git.

Whatever the reason: The result is a broken Git repository that is so non-trivial to fix, that it was easier to clone it fresh from server and apply the missing changes again from the left-over local file of the broken repo.

You can very easily write a sqlite backend if you want. There are a bunch of interesting ones for libgit2[1][2]

1. https://www.perforce.com/blog/your-git-repository-database-p...

2. https://github.com/libgit2/libgit2-backends/blob/master/sqli...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact