Manyana: A Coherent Vision For The Future Of Version Control
59 points by manuel
59 points by manuel
From README.md:
The code in this project was written artisanally. This README was not.
I'm guessing the blog post wasn't either.
I'd honestly prefer LLM code and human docs. At least you'd know what the author thought the code did.
Not me. Other way around. I'd rather the code did exactly what the human understood and intended, and docs be LLM (if not human written) since they're much better suited for that task.
I'm not sure I prefer one over the other, I just want to know which is which, so I know which one to trust. It'd have been nice if the note was at the top, rather than the bottom.
The Pijul version control system also models conflicts using conflict-free replicated datatypes, according to its Theory documentation. Pijul’s Theory docs have mentioned CRDTs since 2021, and Pijul had its first beta release in 2022, yet the only other VCS that Bram mentions is Git. Does Manyana use CRDTs differently, or did Bram accidentally recreate Pijul?
A traditional VCS gives you [these conflict markers]:
[…] Two opaque blobs. You have to mentally reconstruct what actually happened.
Only if you don’t set Git’s merge.conflictStyle configuration to "diff3" or "zdiff3". If you do that, Git’s conflict markers show the base version as well:
<<<<<<< left
||||||| base
def calculate(x):
a = x * 2
b = a + 1
return b
=======
def calculate(x):
a = x * 2
logger.debug(f"a={a}")
b = a + 1
return b
>>>>>>> right
This provides enough context for a developer or a merge tool to infer the same information provided by Manyana’s conflict markers: that the right side added the logger line.
In this example, a human reading the raw conflict markers would find the added line more easily with Manyana style than with kdiff3 style. Manyana-style conflict markers wouldn’t help me, though – I always use a merge tool. No style of conflict markers can replicate a merge tool’s ability to show the base, left, right, and merged versions side by side, free of distracting markers.
[Bram Cohen = creator of BitTorrent and other stuff.]
I’m no expert on VCS theory, but this seems a really good idea. I especially like the extra information presented in conflict handling.
He's been thinking about this for at least 15 years! https://bramcohen.livejournal.com/74462.html
Bram has been thinking about VCS since at least 2005. He invented (?) patience diff https://bramcohen.livejournal.com/37690.html
Reminds me of Pijul though I don't know enough about patch and CRDT theories to appreciate the differences.
I hope these projects succeed, but I think Git's moat is more the network effect than tech. Something like Jujutsu's 2 way interop with Git seems required to bootstrap a community large enough to make a dent in Git (and even Jujutsu is not there yet IMO).
In the meantime, I'll keep my pragmatic approach: Git with AST based merge (Mergiraf) and diff (difftastic). That reduces conflicts a lot, and makes looking at diffs acceptable. Combined with a TUI, actually using Git is no longer a chore I keep procrastinating.
It's good to see effort going into evolving git. Compare this to jj, which keeps the same core git, but is focused on the ergonomics. I gave jj a shot -- In my case I realized at some point that I subconsciously avoided/routed around merge conflicts in a bunch of subtle ways (especially 3-way merge).
Getting my head around this new mental model might break. Then again, this has the chance to work more seamlessly. I think where that balance lands will be important.
As an aside, I've found AI is pretty terrible at rebase/squash/friends, which is a real pain in my workflow. Something like this might have legs just because of that.
JJ conflict marking is already about this good. For the given example it looks like:
<<<<<<< conflict 1 of 1
+++++++ wlzskswp aa967223
%%%%%%% diff from: kwtttmkp ecf04e6a
\\\\\\\ to: tkpomwtt 00055d2e
def calculate(x):
a = x * 2
+ logger.debug(f"a={a}")
b = a + 1
return b
>>>>>>> conflict 1 of 1 ends
I've found AI is pretty terrible at rebase/squash/friends, which is a real pain in my workflow.
I've seen the opposite. I wonder why our experiences are so different.
I suspect it’s the shape of the change. Single conflict or clean branch and it’s a powertool.
Once you get into stacked commits, deletes/renames, or especially messy ancestry it gets risky -- I've also noticed it tends to greatly favor changes in it's current branch, which isn’t that surprising given the context bias. So new feature/change on main gets downrated or clobbered.
That said, tuning the rebase skill and nudging it towards the right ancestor has helped a lot. Might just be a couple of bad early experiences on my side has made me nervous. My original approach was "rebase this" and the results were mixed indeed.
Also it might just be that I'm rebasing more often and just feels more frequent?
I’m wondering how this relates to other version control ideas. It sounds like a combination of the old weave file format used by SCCS / Bitkeeper / Codeville, plus support for first-class conflicts similar to jj, based on an observation that first-class conflicts allow the version control system to be a lossless CRDT, and the weave is a good way to implement it.
I thought Larry McVoy had written something about the advantages of the weave for this kind of thing, but I haven’t found anything by him. But I did find a some informative pages that ~tonyg rescued from the old revctrl wiki:
Document the SCCS weave and Intro to binary weave are what Larry pointed me toward in an email exchange on this very topic.
He did, on the TUHS mailing list:
https://www.tuhs.org/pipermail/tuhs/2019-September/018472.html
Also see these by Marc Rochkind:
https://www.tuhs.org/pipermail/tuhs/2015-November/007610.html
http://web.archive.org/web/20041226000820if_/http://basepath.com:80/aup/talks/SCCS-Slideshow.pdf
Ah yes, that’s the post I was thinking of!
There’s also some interesting discussion about RCS in that thread, especially Eric Allman’s messages. I commented on that thread about having had to deal with RCS’s quadratic behaviour. I didn’t mention that RCS is a lot faster than SCCS if you are operating on HEAD and thereby avoid its linear history walk; SCCS by contrast slows down uniformly as the history grows.
I’m mildly dubious about file-based version control storage, partly because I was convinced by Torvalds’s arguments against bzr’s approach back in 2005; but more recently there have been some interesting optimizations to git’s packfile algorithms that makes it better at cross-file delta compression.
Wrt the weave, it’s also not clear to me that git-blame needs optimizing at the expense of everything else: it seems clear that making HEAD fast is a good strategy. And though it’s neat that the weave works nicely with first-class conflicts, jj shows that it isn’t necessary.
As a vision this strikes me as the first really meaningful advance over git. I really hope this becomes something fully featured and fast.
CRDTs showing conflicts is better than the systems that assume that just because you can merge deterministically that the result makes sense.
However, maybe it's that I'm used to the other model (and I'm not saying it's perfect), but it took me a bit to understand what the conflict of Manyana meant.
This is one feature of future VCS. And I would argue that it's simply insufficient. Pijul tried this, hell, the old schoolers would know that GetSturdy, a previous incarnation of GitButler, also tried CRDTs and failed to find product market fit.
I think it's simply insufficient to create a niche VCS today and try to replace Git with it. You need a functional business, with real revenue, acting as the forcing function to converge and optimize for a better User Experience. You also need to couple it open source, at least on the client-side and transport level, to drive adoptions. And that's hard, one feature won't do it, you need a suite of features with user-driven product market fit.