People are talking about ACID, which comes with SQLite for certain, but here's the biggest thing: all that regular data, which has specific relationships to each other, is available in a well understood, battle tested high level language. Not Perl, not Python, not Tcl, but SQL. Some people criticize fossil as unsuitable for the task of managing all the subtle relationships and being able to deftly handle lots of data, because it's written in C. They're missing the forest for the trees. SQL does the heavy lifting here.
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.
Git and Fossil ultimately deal with fundamentally the same data in the form of atomic artifacts. git chose the way to store the blobs itself on the filesystem so it had to implement a special file format along with special tools to make sure those formats could be read and written correctly. Basically git's interface to the storage are open() and read() system calls.
On the other hand fossil chose to store its artifacts in a SQL database because it makes interaction much much easier (it's just a SELECT; the SQL engine does the rest). Moreover, since fossil has access to a SQL database, it can cache a lot of information to make future extraction of information easier: instead of scanning the whole database on every read (or building a custom index as git does) you can create custom tables for your use case that point to the correct artifacts. Oh and SQLite is just an implementation detail, the real thing that matters is SQL.
So the real advantage of using SQL(ite) is in querying the data to produce all reports you want: list of commits/checkins, list of changes related to a file, list of issues linked to a given file, ...
That said, when you have an extremely simple data model and you have few different access patterns for which SQL wouldn't be of great use anyway, you can have your own file format as git does.
Well, yes, but mainly that fact that you get the ACID guarantees for free: Atomicity, Consistency, Isolation, Durability: http://en.wikipedia.org/wiki/ACID
