5 ms·

Transaction support. No work is left midway. A Git repo might get corrupt in case of power failure. (Never experienced that though)

flogic 12y ago
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.
deleted 12y ago
[deleted]
wereHamster 12y ago
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).
- dezgeg 12y ago
  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.
  - beagle3 12y ago
    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.
beagle3 12y ago
No, it generally cannot. 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.
- ludwigvan 12y ago
  Thanks for the detailed explanation, I stand corrected.

flogic 12y ago

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.

deleted 12y ago

[deleted]

wereHamster 12y ago

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).

dezgeg 12y ago
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.
- beagle3 12y ago
  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.

beagle3 12y ago

No, it generally cannot. 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.

ludwigvan 12y ago
Thanks for the detailed explanation, I stand corrected.