There is no such a thing as «subsequent commits» in git.

Commits in git are non-linear and form a tree[0][1]. A commit can be easily deleted without affecting the rest of the tree. If the git commit represent a subtree with branches dangling off it, deleting such a commit will delete the entire subtree. Commits can also be moved around, detached and re-attached to other commits.

[0] https://www.baeldung.com/ops/git-objects-empty-directory#2-g...

[1] https://www.baeldung.com/ops/git-trees-commit-tree-navigatio...

▲

kstrauser 3 days ago | parent [-]

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.

▲

inkyoto 3 days ago | parent [-]

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.

[0] https://www.techtarget.com/searchCIO/definition/ledger-datab...

[1] https://www.moderntreasury.com/learn/ledger-database

▲

kstrauser 3 days ago | parent [-]

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.