With this in place, and ideally with allowing folks to define custom backends using the plugin interface (decoupled from core, versioned) this story could make a ton of sense.
Disclosure: I’m on the steering committee of OpenTofu.
This means that if you have a CD pipeline (triggered itself by a commit) that does `terraform deploy`, you'd need to have your CD pipeline do commit _again_ to save the changes to the TF state files.
On top of that, you lose the ability to re-run a previous CD pipeline to rollback to a previous version of your infrastructure.
The goal of Git is just to store the lifecycle of a piece of software, imo. It's not the reponsibility of the repo to know the state of the deployment.
But I agree that the gain from that is not crazy.
If the answer is "you should never branch and merge state files", then the corollary is "you should never put state files in source control".
Versioning your state is a good idea and is already easy to do. For example if you use the S3 backend you can enable object versioning on your bucket and then everytime the state is updated it is versioning and you can rollback state that way. It is a good practice. Similarly, you could use the local state backend, which just keeps state in a json file in your project and then you could commit that json file to version control. Now git is versioning your state.
But the author is not suggesting this, they are suggesting to not have a state file at all. You look at previous commits to determine state. So for example if you create a new resource for an ec2 instance in your code and run terraform apply, how does Terraform know it is new and needs to create this ec2 instance as opposed to updating an existing one? Normally it would look at the statefile and if it isn't in there, then tf knows to create it, if it is already in state then it knows to update it and reconcile the metadata in state to the declarative state in the code. But without a statefile this can't be done. So the author looks in the git history at the previous commit. If you can find the resource block in the commit history you know what it was last set to. If it doesn't exist in the history but exists in the current file, then it is presumed that the resource is new. If the resource was in the previous history but is different in the current commit then it is presumed that those changes need to be applied.
I'm sure this works in simple use-cases. But at any moderate scale this could break down very quickly.
The author wants to eliminate state, so they suggest using git because as it turns out... you do need state.
But the author didn't eliminate state at all, they just eliminated a seperate statefile. If that's what bothered them, then sure, the problem is solved. But now you are using version control as state and those don't always line up. If you only work linearly then it is perfect. But what happens when you need to start tracking a pre-existing resource? You have to import it into git history somehow.
Back to your point, you really should not be modifying git history at all. There are tools to do so, but anytime you modify git history it is technically a mis-use of git. There are side-effects of doing so, especially when working on a large distributed team.
Basically the author trades one minor problem for many major problems.
There are many cases I would accept simple hashes vs client side encryption, too. Everyone is going to have different needs but it makes no sense HC ignored making this better for so long.
In Terraform’s defense, it’s often the fault of providers and/or APIs.
This would work the same as state locking works now. You can apply an extra provider for state encryption/decryption just like you do for state locking/unlocking.
It's already been requested (with pull requests) for Terraform for a while now and Hashicorp keeps rejecting it, presumably because it would undermine features of Terraform enterprise.
OpenTofu is already considering implementing this feature as a result.