And everything in Fossil is stored in SQLite, not flat files like most other systems. Seems weird at first, until you think about the advantage of storing things in an ACID database.
http://code.activestate.com/lists/tcl-core/7985/
Edit: add list of current/past members
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.
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.
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.