Point no. 1: > Ledgers are quite easy to build.
Cryptographically provable, tamper-proof ledgers that will sustain a 3rd party compliance certification are not easy to build, they are expensive to build, test and certify (very expensive!), and are very expensive to operate, especially in large scale environments.
Point no. 2: > Git is a ledger.
git is not a proper ledger due to the lack of two fundamental properties of a ledger, as originally stated:
1. an immutable, tamper proof, append-only transaction log;
git does not satisfy this requirement by virtue of allowing one to tamper with the commit history. Write access to commits is the major offender here as it is there, and it opens the door for the commit history abuse. An append-only transaction log also offers a linear, entirely immutable, history (a very important quality from the compliance perspective!), whereas git (by virtue of allowing branches) allows for a non-linear, mutable, temporal history that breaks the linear progression of revisions of valuable documents/assets being stored in it.
2. cryptographically verifiable datasets;
git offers a limited facility into the verification due to allowing one to modify the commit trees, and, by extension, to rewrite the commit history. A git commit history can't be trusted to from the compliance perspective.
What I am sensing is a misconstruction of the purpose of git. git is designed to track changes but not to provide the evidence of changes having not been tampered with. Both purposes have their own places and their own use cases, and the git design is sound and solid, yet it serves an entirely different purpose altogether, and – no – it can't be repurposed as a ledger. That is the case I am arguing.