> If we could just get off the tree-of-diffs model.

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.

FYI you two are talking past each other. Snapshots and diffs are isomorphic to each other.

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.

It depends on what you do with version control. I maintain a long-lived fork of an actively developed upstream project. I spend a ridiculous and unnecessary amount of time in my depressingly short life rebasing changes for every release. 98% of this work would be eliminated if we had patch commutativity.

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.