HN

Comments (78)

• Menu

  ulrikrasmussen
  The thing about how merges are presented seems orthogonal to how to represent history. I also hate the default in git, but that is why I just use p4merge as a merge tool and get a proper 4-pane merge tool (left, right, common base, merged result) which shows everything needed to figure out why there is a conflict and how to resolve it. I don't understand why you need to switch out the VCS to fix that issue.
• nkmnz
  I don't quite understand how CRDTs should help with merges. The difficult thing about merges is not that two changes touch the same part of the code; the difficult thing is that two changes can touch different parts of the code and still break each other - right?
• Menu

  radarsat1
  Is it a good thing to have merges that never fail? Often a merge failure indicates a semantic conflict, not just "two changes in the same place". You want to be aware of and forced to manually deal with such cases.I assume the proposed system addresses it somehow but I don't see it in my quick read of this.
• Menu

  simonw
  This thing is really short. https://github.com/bramcohen/manyana/blob/main/manyana.py is 473 lines of dependency-free Python (that file only imports difflib, itertools and inspect) and of that ~240 lines are implementation and the rest are tests.
• Menu

  bos
  This is sort of a revival and elaboration of some of Bram’s ideas from Codeville, an earlier effort that dates back to the early 2000s Cambrian explosion of DVCS.Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper).Codeville predates the introduction of CRDTs by almost a decade, and at least on the face of it the two concepts seem like a natural fit.It was always kind of difficult to argue that weaves produced unambiguously better merge results (and more limited conflicts) than the more heuristically driven approaches of git, Mercurial, et al, because the edit histories required to produce test cases were difficult (at least for me) to reason about.I like that Bram hasn’t let go of the problem, and is still trying out new ideas in the space.
• Menu

  gnarlouse
  I think something like this needs to be born out of analysis of gradations of scales of teams using version control systems.- What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts?- What do teams of 1, 10, 100, 1k, etc care the most about?- How does the modern "agent explosion" potentially affect this?For example, my experience working in the 1-100 regime tells me that, for the most part, the kind of merge conflict being presented here is resolved by assigning subtrees of code to specific teams. For the large part, merge conflicts don't happen, because teams coordinate (in sprints) to make orthogonal changes, and long-running stale branches are discouraged.However, if we start to mix in agents, a 100 person team could quickly jump into a 1000 person team, esp if each person is using subagents making micro commits.It's an interesting idea definitely, but without real-world data, it kind of feels like this is just delivering a solution without a clear problem to assign it to. Like, yes merge-conflicts are a bummer, but they happen infrequently enough that it doesn't break your heart.
• Menu

  ZoomZoomZoom
  The key insight in the third sentence?> ... CRDTs for version control, which is long overdue but hasn’t happened yetPijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it.Not that Bram is not one of those, but the post reads like you all know what.
• bob1029
  I think there are still strong advantages to the centralized locking style of collaboration. The challenge is that it seems to work best in a setting where everyone is in the same physical location while they are working. You can break a lock in 30 seconds with your voice. Locking across time zones and date lines is a nonstarter by comparison.
• BlueHotDog2
  This is cool and i keep thinking about CRDTs as a baseline for version control, but CRDTs has some major issues, mainly the fact that most of them are strict and "magic" in the way they actually converge(like the joke: CRDTs always converge, but to what). i didn't read if he's using some special CRDT that might solve for that, but i think that for agentic work especially this is very interesting
• Menu

  mikey-k
  Interesting idea. While conflicts can be improved, I personally don't see it as a critical challenge with VCS.What I do think is the critical challenge (particularly with Git) is scalability.Size of repository & rate of change of repositories are starting to push limits of git, and I think this needs revisited across the server, client & wire protocols.What exactly, I don't know. :). But I do know that in my current role (mid-size well-known tech company) is hitting these limits today.
• WCSTombs
  For the conflicts, note that in Git you can do git config --global merge.conflictstyle diff3 to get something like what is shown in the article.
• lasgawe
  This is a really interesting and well thought out idea, especially the way it turns conflicts into something informative instead of blocking. The improved conflict display alone makes it much easier to understand what actually happened. I think using CRDTs to guarantee merges always succeed while still keeping useful history feels like a strong direction for version control. Looks like a solid concept!
• Menu

  lemonwaterlime
  See vim-mergetool[1]. I use it to manage merge conflicts and it's quite intuitive. I've resolved conflicts that other people didn't even want to touch.[1]: https://github.com/samoshkin/vim-mergetool
• a-dub
  doesn't the side by side view in github diff solve this?conflict free merging sounds cool, but doesn't that just mean that that a human review step is replaced by "changes become intervals rather than collections of lines" and "last set of intervals always wins"? seems like it makes sense when the conflicts are resolved instantaneously during live editing but does it still make sense with one shot code merges over long intervals of time? today's systems are "get the patch right" and then "get the merge right"... can automatic intervalization be trusted?edit: actually really interesting if you think about it. crdts have been proven with character at a time edits and use of the mouse select tool.... these are inherently intervalized (select) or easy (character at a time). how does it work for larger patches can have loads of small edits?
• newsoftheday
  OK, I'll stick with git.
• Menu

  logicprog
  This seems like an excellent idea. I'm sure a lot of us have been idly wondering why CRDTs aren't used for VCS for some time, so it's really cool to see someone take a stab at it! We really do need an improvement over git; the question is how to overcome network effects.
• socalgal2
  > [CRDT] This means merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one state comes out, and it’s always correct.Funny, there was just a post a couple of days ago how this is false.https://news.ycombinator.com/item?id=47359712
• Menu

  jFriedensreich
  starts with “based on the fundamentally sound approach of using CRDTs for version control”. How on earth is crdt a sound base for a version control system? This makes no sense fundamentally, you need to reach a consistent state that is what you intended not what some crdt decided and jj shows you can do that also without blocking on merges but with first level conflicts that need to be resolved. ai and language aware merge drivers are helping so much here i really wonder if the world these “replace version control” projects were made for still exists at all.
• Menu

  mentalgear
  > [CRDT] This means merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one state comes out, and it’s always correct.Well, isn't that what the CRDT does in its own data structure ?Also keep in mind that syntactic correctness doesn't mean functional correctness.
• phtrivier
  A suggestion : is there any info to provide in diffs that is faster to parse than "left" and "right" ? Can the system have enough data to print "bob@foo.bar changed this" ?
• Menu

  lifeformed
  My issue with git is handling non-text files, which is a common issue with game development. git-lfs is okay but it has some tricky quirks, and you end up with lots of bloat, and you can't merge. I don't really have an answer to how to improve it, but it would be nice if there was some innovation in that area too.
• sibeliuss
  Why must everyone preprocess their blog posts with ChatGPT? It is such a disservice to ones ideas.
• Menu

  codemog
  Nobody should have these types of problems in the age of AI agents. This kind of clean up and grunt work is perfect for AI agents. We don’t need new abstractions.
• jauntywundrkind
  In case the name doesn't jump out at you, this is Bram Cohen, inventory of Bittorrent. And Chia proof-of-storage (probably better descriptions available) cryptocurrency. https://en.wikipedia.org/wiki/Bram_CohenIt's not the same as capturing it, but I would also note that there are a wide wide variety of ways to get 3-way merges / 3 way diffs from git too. One semi-recent submission (2022 discussing a 2017) discussed diff3 and has some excellent comments (https://news.ycombinator.com/item?id=31075608), including a fantastic incredibly wide ranging round up of merge tools (https://www.eseth.org/2020/mergetools.html).However/alas git 2.35's (2022) fabulous zdiff3 doesn't seems to have any big discussions. Other links welcome but perhaps https://neg4n.dev/blog/understanding-zealous-diff3-style-git...? It works excellently for me; enthusiastically recommended!
• Menu

  skybrian
  It sounds interesting but the main selling point doesn’t really reasonate:If you haven’t resolved conflicts then it probably doesn’t compile and of course tests won’t pass, so I don’t see any point in publishing that change? Maybe the commit is useful as a temporary state locally, but that seems of limited use?Nowadays I’d ask a coding agent to figure out how to rebase a local branch to the latest published version before sending a pull request.
• alunchbox
  Jujutsu honestly is the future IMO, it already does what you have outlined but solved in a different way with merges, it'll let you merge but outline you have conflicts that need to be resolved for instance.It's been amazing watching it grow over the last few years.
• monster_truck
  Not this again
• hahhhha500012
  [dead]
• hahaddmmm12x
  [dead]
• hahaddmmm12x
  [dead]
• hahaddmmm12x
  [dead]