3 ms·

> Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the

> Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit. So, git history is immutable. You can't modify commits without breaking the chain of hashes. It's by definition append only. You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history. People tend to use this to clean up their local change history before they send it upstream. With the exception of force push (i.e. just overwrite the remote repository), there is no way to merge a rewritten history. In order to merge changes, there MUST be a shared commit with the same history. It's not optional.

inkyoto 4y ago
> Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. I am well acquainted with git internals and object types, which include blobs, trees, commits, and tags. But I do acknowledge that I was wrong about git not hashing the object's contents – it does. > A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit. Commits in git are grouped into commit trees that form a single atomic commit, and git allow manipulations of the commit trees, which is fundamentally unacceptable for an immutable, verifiable ledger. That is why I am asserting that git is not an acceptable technology for a ledger. > You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history. I have personally squashed commits in my local project copy and force pushed such a squashed commit into a upstream repository thereby completely decimating the commit history in the upstream repository. Previous commit history was completely gone every single time. It is an occasionally useful feature (i.e. fixing mistakes of young developers), but the commit history rewrite is absolutely unacceptable in the compliance world. Just the fact that there is direct, unabridged write access to the history or to the storage where the history is recorded makes such a solution untenable as a ledger database. I do concede that there are some conceptual similarities between git and ledger databases at the architectural level; I do, however, vociferously dispute the suitability of git as a foundation for building a ledger database without a substantial rewrite of the git foundation.
- unionpivo 4y ago
  You can do the same things with ledger databases, it's just no so convenient, as just typing --force If you have permission to replace database with with your new one (or spin up new instance of DB, adn redirect app to use that, depending on how you are set up), it's just not as convenient (by design). I used centera WORM disks at my previous jobs, for added guarantees. (not by choice, stay away of you have a choice) And once the GDPR came out, and we had to remove some content, that's what we did, made a copy, with bad data removed, nuked centera clean, (created new partition, and disabled old one) and restored now clean data on. As far as our applications were concerned nothing happened.
  - inkyoto 4y ago
    You are not incorrect. Ledger databases, as a technology, do not eliminate a possibility of spinning up a shadow ledger and rebuilding the change history in the new ledger that is purged of inconvenient records. Managed ledger database services in the cloud (e.g. QLDB in AWS) offer a partial solution to the problem such as platform generated timestamps in the delete/change history table (hard to forge), delete operations not actually deleting the data but moving it into a separate history table, the separation of access to the ledger (app vs account administrator), disallowing direct access to the storage, setting up anomaly detection alarms in the monitoring layer etc etc. But none of that precludes the possibility of a ledger being nuked or rebuilt (and later nuked).
- jillesvangurp 4y ago
  You were arguing it's not a proper merkle tree and it is. You are not a little bit wrong there but flat out barking up the wrong tree. It's a merkle tree with full immutability and append only behavior. This is not an accidental/conceptual similarity. It's the single most important design decision that Git is based on. Force push only allows you to wipe out repositories that you control. The whole point of git is that you do not need write access at all to share commits. That's why it's called a pull request and not a push demand. You invite others to look at and maybe merge your changes. There is no way to force the other side to do that and force push rewriting their commit history is not going to help your case for obvious reasons.

inkyoto 4y ago

> Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong. I am well acquainted with git internals and object types, which include blobs, trees, commits, and tags. But I do acknowledge that I was wrong about git not hashing the object's contents – it does. > A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit. Commits in git are grouped into commit trees that form a single atomic commit, and git allow manipulations of the commit trees, which is fundamentally unacceptable for an immutable, verifiable ledger. That is why I am asserting that git is not an acceptable technology for a ledger. > You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history. I have personally squashed commits in my local project copy and force pushed such a squashed commit into a upstream repository thereby completely decimating the commit history in the upstream repository. Previous commit history was completely gone every single time. It is an occasionally useful feature (i.e. fixing mistakes of young developers), but the commit history rewrite is absolutely unacceptable in the compliance world. Just the fact that there is direct, unabridged write access to the history or to the storage where the history is recorded makes such a solution untenable as a ledger database. I do concede that there are some conceptual similarities between git and ledger databases at the architectural level; I do, however, vociferously dispute the suitability of git as a foundation for building a ledger database without a substantial rewrite of the git foundation.

unionpivo 4y ago
You can do the same things with ledger databases, it's just no so convenient, as just typing --force If you have permission to replace database with with your new one (or spin up new instance of DB, adn redirect app to use that, depending on how you are set up), it's just not as convenient (by design). I used centera WORM disks at my previous jobs, for added guarantees. (not by choice, stay away of you have a choice) And once the GDPR came out, and we had to remove some content, that's what we did, made a copy, with bad data removed, nuked centera clean, (created new partition, and disabled old one) and restored now clean data on. As far as our applications were concerned nothing happened.
- inkyoto 4y ago
  You are not incorrect. Ledger databases, as a technology, do not eliminate a possibility of spinning up a shadow ledger and rebuilding the change history in the new ledger that is purged of inconvenient records. Managed ledger database services in the cloud (e.g. QLDB in AWS) offer a partial solution to the problem such as platform generated timestamps in the delete/change history table (hard to forge), delete operations not actually deleting the data but moving it into a separate history table, the separation of access to the ledger (app vs account administrator), disallowing direct access to the storage, setting up anomaly detection alarms in the monitoring layer etc etc. But none of that precludes the possibility of a ledger being nuked or rebuilt (and later nuked).
jillesvangurp 4y ago
You were arguing it's not a proper merkle tree and it is. You are not a little bit wrong there but flat out barking up the wrong tree. It's a merkle tree with full immutability and append only behavior. This is not an accidental/conceptual similarity. It's the single most important design decision that Git is based on. Force push only allows you to wipe out repositories that you control. The whole point of git is that you do not need write access at all to share commits. That's why it's called a pull request and not a push demand. You invite others to look at and maybe merge your changes. There is no way to force the other side to do that and force push rewriting their commit history is not going to help your case for obvious reasons.