A git repo is always consistent: when putting stuff into the repo, you add complete files to the "loose object" directory, and then modify the ref while holding a lock (and doing a "compare-and-swap" under that lock).
Which means that, as long as the filesystem does not reorder operations such that later operations are visible before earlier ones (and a sane system does not - in that sense, ext3, ext4 and NTFS are all sane), you are either before the ref change (at the old version) or after the ref change (the new version) - any other state is not accessible.
There is nothing magical about SQLite's transaction support. If the operating system reorders files across an fsync(), both sqlite and git will corrupt. If it doesn't, it won't.
Git is transactional and ACID. And unlike SQLite (or even Oracle for that matter), when "git fsck" says "ok", you know that there is no error in the data (caused by bad memory, undetected disk error, etc). Repository integrity is fundamentally inherent to how git works.
EDIT: Just to point out: fossil does keep SHA1 hashes of everything, so it can find problems just as well as git does - but sqlite itself generally cannot.
Not if you use a proper filesystem and disk drives which don't lie to the operating system. These may also cause problems for sqlite. After all, sqlite is only as robust as the legs it stands on (filesystem, drivers, kernel, disk).
I'd still trust sqlite to be more reliable than git. For instance, I've previously had git crash and burn with some extremely obscure error message when disk space ran out.
git's error reporting and command line are not exactly friendly, but reliability and friendliness are orthogonal.
So git crashed and burned. Was anything corrupted?
Now for a question. Say, Mr. Evil Gamma Ray flipped one bit on your data somewhere. Git is guaranteed to detected this. SQLite is unlikely to. There's an actual reliability difference here, and it is in Git's favor.
EDIT: Just to point out: fossil does keep SHA1 hashes of everything, so it can find problems just as well as git does - but sqlite itself generally cannot.
As far as I could tell at the time, I've had git fuck up on windows. I switched to the prod branch, did pull, and it merged the test branch into prod. Then, I deployed it, because I was in a hurry and didn't notice. Fortunately, it wasn't disastrous. That's when I switched back to using Linux as my primary dev environment.
A git repo is always consistent: when putting stuff into the repo, you add complete files to the "loose object" directory, and then modify the ref while holding a lock (and doing a "compare-and-swap" under that lock).
Which means that, as long as the filesystem does not reorder operations such that later operations are visible before earlier ones (and a sane system does not - in that sense, ext3, ext4 and NTFS are all sane), you are either before the ref change (at the old version) or after the ref change (the new version) - any other state is not accessible.
There is nothing magical about SQLite's transaction support. If the operating system reorders files across an fsync(), both sqlite and git will corrupt. If it doesn't, it won't.
Git is transactional and ACID. And unlike SQLite (or even Oracle for that matter), when "git fsck" says "ok", you know that there is no error in the data (caused by bad memory, undetected disk error, etc). Repository integrity is fundamentally inherent to how git works.
EDIT: Just to point out: fossil does keep SHA1 hashes of everything, so it can find problems just as well as git does - but sqlite itself generally cannot.