It's not quite what you're asking for, but Jujutsu+Git is still a much better dev experience than Git alone and is completely compatible with those sites.
I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :)
...I think my PRs have gotten noticeably cleaner and easier to review, though!
Lipstick on a pig, I'm sorry to say. Especially jujutsu which is literally just a wrapper for git.
These tools have better CLI for sure, and some nice added features too. VCS-integrated collaboration tools in fossil is nice. But my point was more along the lines of "why don't we have a radically different architecture that is better matched to the problem domain?"
We have database-backed storage backends for Jujutsu at Google. There's no Git involved there. So I think it's wrong to say that it's a wrapper for Git.
Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.
Do they? They're different and theoretically better in some respects, but are they better in ways that matter and truly deliver value to users?
Commutativity of patches is neat, but it's just not that big a deal. I think Pijul's best feature is first-class conflicts, an idea that Jujutsu has also incorporated.
Git is the radically different architecture. Before it we had RCS, CVS, SVN, and a host of others that were simply striving to improve on the RCS model... a model that was simply unable to scale to large distributed projects with many collaborators.
Torvalds dreamed up Git in a weekend, and it's radically different from the patch-tree stuff that came before it. It's not taken over the world for no reason.
I lived through all that, I know. Torvalds didn't dream up git btw, it was a bad, but performant copy of monotone's DVCS UI/UX.
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.
> 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.
