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.

▲

inkyoto 2 days ago | parent [-]

I respectfully disagree.

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.

	▲	kstrauser 2 days ago \| parent [-]
		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.