True but irrelevant. You can't remove a commit in a way that someone else with a copy of the repo can't detect, in exactly the same way and for the same reason that you can't remove a blockchain entry without making instantly obviously to later items.
Very much relevant. The definition of the ledger database includes immutability of datasets as a hard constraint[0][1]. The mere fact that the git commit history can be altered automatically disqualifies git from being an acceptable alternative to the ledger database in highly regulated environments.
If strict compliance is not a hard requirement (open source project are the prime example), git can be used to prove provenance, provided you trust the signer’s public key or allowed signers file.
It is immutable in exactly the same way. The git commit history cannot by altered, except in the same sense that you could manually edit the backing store of a blockchain to alter the data, and with the same consequence that the alteration would be instantly noticeable in either case.
Consider a leaf commit (or a leaf which is a subtree of commits). I am a person with nefarious intentions, and I delete the leaf commit, forcefully expire the reflogs, or force garbage collect them. At that point, there is no longer remaining evidence in git that the commit ever existed. If git were to be used to record a history of criminal offences, I would be able to single-handedly delete the last offence by running «git reflog expire --expire=now --all» followed by «git gc --aggressive --prune=now».
Ledger databases, on the other hand, do not have the «delete» operation. The «update» operation does not factually update the document/record and creates a new revision instead (just as git does), whilst retaining a full history of updates to the document/record. This is the fundamental difference.
If you're running a blockchain on a single node, it's exactly like running Git on that single node. You can mutate the data locally, even with something as simple as reverting to a backup. Voila, it never happened.
If you're running Git on multiple nodes, it's exactly like running a blockchain on multiple nodes. You can mutate your own local copy, but that doesn't mutate mine, and the set of commits is functionally identical to the union of commits from every node. You can't delete a commit without deleting it from every clone.
Yes, that is the problem that is impossible to address with git due to its decentralised nature, which is a feature.
A typical scenario that disqualifies git in certain scenarios is as simple as a master repository and a few local copies of varying degree of vintage. Then the master has had its commit history changed, reflogs purged and GC'd, and the local copies will never have the knowledge of what the master could have had in the past.
git is perfectly acceptable in many scenarios, but if the immutability has to be enforced, in regulatory WORM requirements (SEC 17a-4, ISO 14641 or similar) with
1. Certified write-once, read-many retention, legal holds and tamper-evidence anchored to trusted time sources are mandatory;
2. Authoritative time and ordering – git commit timestamps are user-supplied and easily forged;
3. Granular access control and selective disclosure – git tends to replicate whole histories and the ledger can provide the proof of single record only;
4. Structured queries and point-in-time views at scale – git has no native time-travel queries, secondary indexes or ACID multi-record transactions across millions of records with consistent snapshots;
5. Independent third-party verification – if external parties (e.g. state auditors) must verify recorded events, verifiable receipts or Merkle proofs that stand alone are needed. git commits and optional signatures are not receipts and are hard to validate without access to the repository.
6. Consensus or anchoring needs – if integrity must be prove against a hostile or nefarious party, anchoring or consensus is required. git has no native consensus; ledger databases can anchor state hashes to public chains or quorum-backed authorities.
… git is not a really option.
git can be hardedned, though, by signing commits and tags, forbidding force-pushes server-side, mirroring to append-only storage and periodically anchoring repository state to a public timestamping service. It still will not meet strict ledger-grade assurances, but it can raise the bar for internal use. The sheer amount of work required to accomplish that makes a solid case for a dedicated ledger database.
