That's exactly what Git's innovation was, though. It doesn't work with patches or diffs, it works with (essentially) snapshots of the tree, and how they are related to each other.
You need the commit history, because that's the fundamental point of the VCS. Linux devs need to be able to demonstrate the provenance of each piece of code in the tree. That's the problem that git exists to solve.
> it was a bad, but performant copy of monotone's DVCS UI/UX.
I don't think the UI is what makes git, git. AFAIK Torvalds didn't put much thought into workflow or UI design - that evolved later. It's what goes on inside .git/ that's the innovative bit.
What I believe the GP is referring to is commutativity of patches. Personally, as someone with many years of source control experience, I think commutativity is very far down the list of what I think needs fixing.
One of the main jobs of source control is to be able to answer discovery requests when lawyers come knocking. You really need an effectively immutable history of published work for this.
Not everyone is affected by this. I recognize that my use case isn't the median case. But it is a massive and entirely unnecessary burden.
We can do better though. Patch theory shows that we shouldn't even need to care about commit history, for example. If we could just get off the tree-of-diffs model.