[MCRed]

Git commits are hashes of the patches, right? So, while it would be difficult to change the blockchain of bitcoin because its widely distributed and computationally expensive, it wouldn't be too hard to do it to git.

Process would be something like: -- Take the original chain. -- Identify a patch in the past where you want to insert the code -- Check out back to that patch -- Make the change -- Roll forward with all the following patches re-applied (with new hashes of course) -- Replace the repo with the new repo.

The end result is that hashes would change. So if you were talking to people about a particular patch using its hash, or telling people a particular release is set at a particular hash, you would notice when this changes. So it wouldn't be invisible using this method.

An alternative approach might be to generate a series of innocuous code changes that will produce the end result of restoring the hashes of the latest commit to what they should have been before the change. This might be extremely difficult or computationally intensive, unless the hash algo is weak.

But it seems theoretically possible, unless I'm missing something about how git works.

[paulannesley]

That's what `git rebase --interactive` does (which has been described as being “a bit like git commit --amend hopped up on acid and holding a chainsaw–completely insane and quite dangerous but capable of exposing entirely new states of mind”[0])

The scenario described happens frequently when people `git push -f` a rebased tree, and it certainly does not go unnoticed by other developers on the project — more “havoc” than “subtle”.

[0]: http://2ndscale.com/rtomayko/2008/the-thing-about-git