4 ms·

> You can't rewrite history in git without changing commit IDs. But "not changing commit IDs" isn't part of git's utility. Not inherently. This is easily prov

> You can't rewrite history in git without changing commit IDs. But "not changing commit IDs" isn't part of git's utility. Not inherently. This is easily proven by the fact that people do rewrite history. Because it's a useful feature to have. To say that you can't rewrite history without changing commit IDs is like saying you can't prove a certain point without using the letter 'e'. Like… why are you even bringing up such a restriction? > but blockchain means something different in people's mind Right. Blockchain means "distributed ledger", which git is not. To say that git is one too is a technicality on the level of saying it's "wrong" to say "have your cake and eat it too", when it's actually "eat your cake and have it too". It's not wrong, just not meaningful. The only reason, in my opinion, to talk about the similarities between "blockchain" and git is to do exactly what this article does: to remove confusion in the mind of the listener that they are in any way meaningfully similar. > I've seen some interesting PoW proposals, like mail anti-spam, or rate limiting/captcha. Maybe in the future you'll mine the next cryptocurrency by proof of work in the form of "help this self-driving car that's stuck at an intersection it doesn't understand".

mikea1 4y ago
> But "not changing commit IDs" isn't part of git's utility. How is that not a useful, intentional feature of git? Commit IDs (hashes) ensure DAG consistency as well as many other benefits. Linus explains it better than I could[0]. > This is easily proven by the fact that people do rewrite history. Because it's a useful feature to have. It depends on the context. Try to rewrite commits in a PR for any public repo and see whether others agree it's a useful feature. Anyway, I think you're proving the counter point: this is a shared feature of git and block chains - you know when history has been rewritten because the hashes changed. [0] http://www.youtube.com/watch?v=4XpnKHJAok8&t=56m16s http://www.youtube.com/watch?v=4XpnKHJAok8&t=56m16s
- knorker 4y ago
  Sure, it's a hiccup to rewrite history. But in Bitcoin it's 100% fundamental breakage. There's a difference.
  - MayeulC 4y ago
    I think you didn't take the parent's suggestion to make a PR seriously enough. It is closer than you seem to think: rewriting history in a public, published repository will wreak havoc across contributors'clones. Contributors will have to contact upstream and ask if there was a reason, if it was intentional, or a malicious event. Especially if the root commit was changed, in which case you can't even attempt to merge repositories. I don't really see why you couldn't backtrack the bitcoin blockchain, pretend an arbitrary block is the most recent one, and start your fork from there. The difference is,is that if you want to include some subsequent blocks, you will have to provide some proofs of work. In both cases, some convincing is needed to move the consensus base to a new one. https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History In the important note: > One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world. Also: > it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite This is git 101. People can still choose to follow your rewritten history fork though, and it's also the case for bitcoin.
    - knorker 4y ago
      I replied to most things here in https://news.ycombinator.com/item?id=32443447 https://news.ycombinator.com/item?id=32443447 In git it's a hiccup if upstream does it. But it does work. For buttcoin you get the DAO split.
namose 4y ago
It’s important for audit ability and security that people can’t change commit ids from under you. If you run a security review of commit A and decide it’s safe to automatically deploy on your production systems, you’re only doing that because you know commit A can’t be changed.
- knorker 4y ago
  Yes, it's a hiccup. But not fundamental because it is actually possible to do it. A company can have a flag day, and keep a mapping of old hash to new hash for audit purposes. I'm not saying do it willy nilly, but repos are fundamentally below the humans and any needs they have. Blockchains say code is law, and a fork (see eth DAO) is a complete clusterfuck. Scrubbing some PII you legally need to remove from the corp codebase? Some poking, yes, but not a disaster. Whereas they say there's plenty of child porn in the bitcoin Blockchain.

mikea1 4y ago

> But "not changing commit IDs" isn't part of git's utility. How is that not a useful, intentional feature of git? Commit IDs (hashes) ensure DAG consistency as well as many other benefits. Linus explains it better than I could[0]. > This is easily proven by the fact that people do rewrite history. Because it's a useful feature to have. It depends on the context. Try to rewrite commits in a PR for any public repo and see whether others agree it's a useful feature. Anyway, I think you're proving the counter point: this is a shared feature of git and block chains - you know when history has been rewritten because the hashes changed. [0] http://www.youtube.com/watch?v=4XpnKHJAok8&t=56m16s http://www.youtube.com/watch?v=4XpnKHJAok8&t=56m16s

knorker 4y ago
Sure, it's a hiccup to rewrite history. But in Bitcoin it's 100% fundamental breakage. There's a difference.
- MayeulC 4y ago
  I think you didn't take the parent's suggestion to make a PR seriously enough. It is closer than you seem to think: rewriting history in a public, published repository will wreak havoc across contributors'clones. Contributors will have to contact upstream and ask if there was a reason, if it was intentional, or a malicious event. Especially if the root commit was changed, in which case you can't even attempt to merge repositories. I don't really see why you couldn't backtrack the bitcoin blockchain, pretend an arbitrary block is the most recent one, and start your fork from there. The difference is,is that if you want to include some subsequent blocks, you will have to provide some proofs of work. In both cases, some convincing is needed to move the consensus base to a new one. https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History In the important note: > One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world. Also: > it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite This is git 101. People can still choose to follow your rewritten history fork though, and it's also the case for bitcoin.
  - knorker 4y ago
    I replied to most things here in https://news.ycombinator.com/item?id=32443447 https://news.ycombinator.com/item?id=32443447 In git it's a hiccup if upstream does it. But it does work. For buttcoin you get the DAO split.

namose 4y ago

It’s important for audit ability and security that people can’t change commit ids from under you. If you run a security review of commit A and decide it’s safe to automatically deploy on your production systems, you’re only doing that because you know commit A can’t be changed.

knorker 4y ago
Yes, it's a hiccup. But not fundamental because it is actually possible to do it. A company can have a flag day, and keep a mapping of old hash to new hash for audit purposes. I'm not saying do it willy nilly, but repos are fundamentally below the humans and any needs they have. Blockchains say code is law, and a fork (see eth DAO) is a complete clusterfuck. Scrubbing some PII you legally need to remove from the corp codebase? Some poking, yes, but not a disaster. Whereas they say there's plenty of child porn in the bitcoin Blockchain.