Back when I used to work for BitKeeper, having support problems ultimately be traced back to bad memory (or disk, or nfs, ...) was a common occurrence. BK woul

Back when I used to work for BitKeeper, having support problems ultimately be traced back to bad memory (or disk, or nfs, ...) was a common occurrence. BK would checksum everything it writes to disk and verify those checksums when it read it back. And since it uses 'simple' arithmetic checksums rather than 'secure' ones it was possible to pre-compute the checksum we would get when writing new files so even memory errors would be noticed if it changes what we will be writing to disk. The hard part when doing support is convincing the customer that the errors in your software are from their systems. I had to learn the failure patterns of a couple large filers so I could look for them. Now we use git which is fine, and git uses much stronger checksums. My main concern is that since those SHA{1,256} checksums are expensive they are typically generated only once and then only used for lookups. If you intentionally corrupt git files, it is hard to have git notice without explicitly running a check. These checks should be done it cron nightly as part of backups.