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