sqlite is great when everything is working as designed, but breaks completely on any badness.
The file-based git approach is on the other hand is incredibly resilent - and "resilent" is exactly what I want from my version control system.
For example, I sync all my computers, including .git dirs, with unison. And sadly, I am not a perfect human being, so I often generate conflicts (like make different commits on same branch in same git checkout and thentry to sync this using file-based sync tool). And git survives such abuse and just works. It also survives partially deleted files, bad transfers.. sometimes you need to dig a bit, but you can recover it.
sqlite is a proper database that actually tests its resilience.
Just because you can't sync a sqlite file, that doesn't mean it isn't resilient it just means you need to back it up via pushing to another repo or using the backup command. Syncing by just copying files over while a disk is still being used is fragile in general.
"application crash, or an operating-system crash, or even a power failure" - so basically proper atomic renames. git does this well.
unsupported failure modes:
"Backup or restore while a transaction is active" - when you backup your machine, do you really treat each sqlite specially? I know I don't.
"Deleting a hot journal" - or, you know, downloading database file and forgetting to grab journal at the same time
"Multiple links to the same file" - did you ever hardlink or bind-mounted a database file? prepare for corruption...
-----
Don't get me wrong, it takes some skill to implement proper safe file handling, and a random person off the street would be better off with sqlite.
But git specifically took the effort and designed the system so that the database is resilent in all sort of crazy conditions, and even if not, it's easy to recover. Switching git to sqlite would be all downside, no upside.
>when you backup your machine, do you really treat each sqlite specially?
Yes, but only for servers where the database is being used. On my desktop if the database isn't being used it is safe to copy so I don't worry about it. Backing up a git repo while git is writing to the repo isn't safe either.
>or, you know, downloading database file and forgetting to grab journal at the same time
You should not be downloading an actively used sqlite database anyways. If you backup the sqlite database before downloading it there won't be a journal file.
>did you ever hardlink or bind-mounted a database file? prepare for corruption...
You just have to link both the database and WAL file. This is somewhat challenging since the WAL file will be deleted by default if all processes close the database. It's better to link or mount the directory that contains the database file. If you link only some of the files from .git, then git won't work properly either.
