12 ms·

The future of version control

• shitfilleddonut 6mo ago
  It seems more like the past of version control
• bos 6mo ago
  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.
  • dboreham 6mo ago
    Note that CRDT isn't "a thing". The CRDT paper provides a way to think about and analyze eventually consistent replication mechanisms. So CRDTs weren't "introduced", only the "CRDT way of discussing replication". Every concrete mechanism described in the CRDT paper is very old, widely used for decades beforehand. This means that everything that implements eventual consistency (including Git) is using "a CRDT".
    • hrmtst93837 6mo ago
      [flagged]
    • mweidner 6mo ago
      While this is technically correct, folks discussing CRDTs in the context of text editing are typically thinking of a fairly specific family of algorithms, in which each character (or line) is assigned an immutable ID drawn from some abstract total order. That is the sense in which the original post uses the term (without mentioning a specific total order).
  • gritzko 6mo ago
    In 2007 Bram said to me that my Causal Tree algorithm is a variant of weave. Which is broadly correct. In these 20 years, the family of weave-class algos grew quite big. In my 2020 article, I devoted the intro to making their family portrait https://arxiv.org/abs/2002.09511 https://arxiv.org/abs/2002.09511 Could have been a separate article.
  • bramcohen 6mo ago
    The whole point of using a proper CRDT is that it's easy to reason about what it does. It took me a while to figure out the details of how to build one.
• logicprog 6mo ago
  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.
  • righthand 6mo ago
    Well over half of all people can’t tell you the difference between git and Github. The latter being owned by a corporation that needs the network effect to keep existing.
  • vishvananda 6mo ago
    This is actually a very interesting moment to potentially overcome network effects, because more and more code is going to be written by agents. If a crdt approach is measurably better for merging by agent swarms then there is incentive to make the switch. It also much easier to get an agent to change its workflow than a human. The only tricky part is how much git usage is in the training set so some careful thought would need to be given to create a compatibility layer in the tooling to help agents along.
  • NetOpWibby 6mo ago
    Overcoming network effects cannot be the goal; otherwise, work will never get done. The goal should be to build a full spec and then build a code forge and ecosystem around this. If it’s truly great, adoption will come. Microsoft doing a terrible job with GitHub is great for new solutions.
• ZoomZoomZoom 6mo ago
  The key insight in the third sentence? > ... CRDTs for version control, which is long overdue but hasn’t happened yet Pijul 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.
  • simonw 6mo ago
    I hadn't heard of Pijul. My first search took me to https://github.com/8l/pijul https://github.com/8l/pijul which hasn't been updated in 11 years, but it turns out that's misleading and the official repo at https://nest.pijul.com/pijul/pijul https://nest.pijul.com/pijul/pijul had a commit last month. ... and of course it is, because Pijul uses Pijul for development, not Git and GitHub!
    • idoubtit 6mo ago
      The canonical website is https://pijul.org https://pijul.org. The homepage has a link to the pijul source repository.
      • ozten 6mo ago
        They should mirror on GitHub for marketing purposes
        • nicoty 6mo ago
          How would they do that if they don't use git for version control? Does GitHub allow other forms of version control other than git?
          • simonw 6mo ago
            SQLite does it despite using Fossil - their mirror is at https://github.com/sqlite/sqlite https://github.com/sqlite/sqlite Git is so established now that it's sensible for alternative VCS to have a mode where they can imitate the Git protocol - or seven without that you can still checkout the latest version of your repo and git push that on a periodic basis.
• radarsat1 6mo ago
  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.
  • mikey-k 6mo ago
    [flagged]
  • recursivecaveat 6mo ago
    It says that merges that involve overlap get flagged to the user. I don't think that's much more than a defaults difference to git really. You could have a version of git that just warns on conflict and blindly concats the sides.
    • shaftway 6mo ago
      This is kind of how jj handles the situation. git won't let you move on from a rebase if there are conflicts. By comparison, jj will just put a marker in the log pointing out that there are conflicts in a branch. You resolve them whenever you feel like it, but all resolving them does is effectively remove the "conflict" marker and rebase all of the descendent commits (which may clean up merge conflicts, or make them worse).
  • hungryhobbit 6mo ago
    They address this; it's not that they don't fail, in practice... the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails.
    • bigfishrunning 6mo ago
      Isn't that how the current systems work though? Git inserts conflict markers in the file, and then emacs (or whatever editor) highlights them The big red block seems the same as "flagged", unless I'm misunderstanding something
• simonw 6mo ago
  This thing is really short. https://github.com/bramcohen/manyana/blob/main/manyana.py 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.
  • zahlman 6mo ago
    It's really impressive what can be done in a few hundred lines of well-thought-out Python without resorting to brutal hacks. People complain about left-pad incidents etc. in the JS world but I honestly feel like the Python ecosystem could do with more, smaller packages on balance. They just have to be put forward by responsible people who aren't trying to make a point or inflate artificial metrics.
    • josephg 6mo ago
      I bet you can make a small, beautiful implementation of this algorithm in most languages. Most algorithms - even ones that take generations of researchers to figure out - end up tiny in practice if you put the work in to understand them properly and program them in a beautiful way. Transformers are the same. Genius idea. But a very small amount of code to implement. This is an implementation of FugueMax (Weidner and Kleppmann) done using a bunch of tricks from Yjs (Jahns). There’s generations of ideas here, by lots of incredibly smart people. And it turns out you can code the whole thing up in 250 lines of readable typescript. Again with no dependencies. https://github.com/josephg/crdt-from-scratch/blob/master/crdt.ts https://github.com/josephg/crdt-from-scratch/blob/master/crd...
      • zahlman 6mo ago
        I'm not familiar with CRDT but the code does look pretty nice. I actually have been thinking myself of streaming my development, but just the terminal without camera or microphone. (So I think I want to wait until I'm doing something that will look pretty in the terminal.)
  • sayrer 6mo ago
• mikey-k 6mo ago
  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.
  • rectang 6mo ago
    [dead]
  • layer8 6mo ago
    One solution is to decompose your code into modules with stable interfaces and reference them as versioned dependencies.
  • procaryote 6mo ago
    What kind of scalability issues have you had with git? Is it because of a monorepo?
    • mikey-k 6mo ago
      yes - monorepo. Git (and associated service providers) have a lot of work to do to scale out to large organizations working in a single code base. "Better Merge Conflicts" is not on this list. Although I'm sympathetic to the problem, and I've personally worked on "Merge Conflicts at Scale". Some of what's being suggested here is interesting. I question if it makes a material difference in the "age of ai", where an AI can probably go figure out enough context to "figure things out".
      • adastra22 6mo ago
        Merge conflict avoidance is not a monorepo issue. In fact, the whole purpose of a monorepo is to avoid these sorts of issues, so it's not surprising. Merge conflict hell shows up when, for example, you maintain a long-lived feature branch periodically rebased against an indifferent upstream that has its own development priorities. I've maintained a project for years that was in this sort of situation. About ~100 commits on top of upstream, but invasive ones that touched nearly every file. Every six months upstream did a new tagged release. It would take me literally weeks of effort to rebase our patches on top, as nearly every commit triggered its own merge conflict hell. You don't encounter these sorts of issues in a monorepo.
• lifeformed 6mo ago
  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.
  • miloignis 6mo ago
    I really think something like Xet is a better idea to augment Git than LFS, though it seems to pretty much only be used by HuggingFace for ML model storage, and I think their git plugin was deprecated? Too bad if it ends up only serving the HuggingFace niche.
  • rectang 6mo ago
    Has there ever been a consideration for the git file format to allow storage of binary blobs uncompressed? When I was screwing around with the Git file format, tricks I would use to save space like hard-linking or memory-mapping couldn't work, because data is always stored compressed after a header. A general copy-on-write approach to save checkout space is presumably impossible, but I wonder what other people have traveled down similar paths have concluded.
  • zahlman 6mo ago
    What strategies would you like to use to diff the binaries? Or else how are you going to avoid bloat? Is it actually okay to try to merge changes to binaries? If two people modify, say, different regions of an image file (even in PNG or another lossless compression format), the sum of the visual changes isn't necessarily equal to the sum of the byte-level changes.
    • jayd16 6mo ago
      The best solution I've seen is prevention. What you can do in P4 is work in trunk, make sure you have latest and lock binary files you're working on. If you do that you won't have conflicts (at the file level anyway). Unlike git's design, this collaborative model is centralized and synchronous but it works. Git is missing the built in binary support, the locking, and the efficient information sharing of file status tracking. With LFS you can cobble something together but it's not fast or easy. I'm all for other solutions but I wish git would at least support this flow more whole heartedly until something else is invented.
• gnarlouse 6mo ago
  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.
  • CuriouslyC 6mo ago
    Team scale doesn't tend to impact this that much, since as teams grow they naturally specialize in parts of the codebase. Shared libs can be hotspots, I've heard horror stories at large orgs about this sort of thing, though usually those shared libs have strong gatekeeping that makes the problem more one of functionality living where it shouldn't to avoid gatekeeping than a shared lib blowing up due to bad change set merges.
  • tasuki 6mo ago
    > 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? Oh god no! That would be about the worst way to do it. Just make it conceptually sound.
    • gnarlouse 6mo ago
      Probably, but just introducing CRDTs also feels like the wrong way to approach the problem! :)
• jFriedensreich 6mo ago
  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.
  • miloignis 6mo ago
    The rest of the article shows exactly how a CRDT is a sound base for a version control system, with "conflicts" and all.
    • skydhash 6mo ago
      But the presentation does not show how it resolves conflicts. For the first example, Git has the 3 way-merge that shows the same kind of info. And a conflict is not only to show that two people have worked on a file. More often than not, it highlight a semantic changes that happened differently in two instances and it's a nice signal to pay attention to this area. But a lot of people takes merge conflicts as some kind of nuisance that prevents them from doing their job (more often due to the opinion that their version is the only good one).
    • jFriedensreich 6mo ago
      where?
  • nozzlegear 6mo ago
    > 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. I really wonder what kinds of magical AI you're using, because in my experience, Claude Code chokes and chokes hard on complex rebases/merge conflicts to the point that I couldn't trust it anymore.
• jauntywundrkind 6mo ago
  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_Cohen https://en.wikipedia.org/wiki/Bram_Cohen It'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 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 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-conflict-markers https://neg4n.dev/blog/understanding-zealous-diff3-style-git...? It works excellently for me; enthusiastically recommended!
• ulrikrasmussen 6mo ago
  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.
  • crote 6mo ago
    Seconding the use of p4merge for easy-to-use three-pane merging. Just like most other issues with Git, if your merges are painful it's probably due to terrible native UX design - not due to anything conceptually wrong with Git.
    • TacticalCoder 6mo ago
      Thirding it except I do it from Emacs. Three side-by-side pane with left / common ancestor / right and then below the merge result. By default it's not like that but then it's Emacs so anything is doable. I hacked some elisp code a great many years ago and I've been using it ever since. No matter the tool, merges should always be presented like that. It's the only presentation that makes sense.
      • MarsIronPI 6mo ago
        What tool do you use? Does Magit support it natively?
        • skydhash 6mo ago
          I think you need to enable 3 way merge by default in git's configuration, and both smerge (minor mode for solving conflicts) and ediff (major mode that encompass diff and patch) will pick it up. In the case of the latter you will have 4 panes, one for version A, another for version B, a third for the result C, and the last is the common ancestor of A and B. Addendum: I've since long disabled it. A and B changes are enough for me, especially as I rebase instead of merging.
• lemonwaterlime 6mo ago
  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 https://github.com/samoshkin/vim-mergetool
  • mentalgear 6mo ago
    Looks like vscode diff view .
• skybrian 6mo ago
  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.
  • deleted 6mo ago
    [deleted]
  • dcre 6mo ago
    This is a reasonable reaction — pretty sure I felt the same way when I heard about jujutsu's first-class conflicts[0] — but it turns out to be really useful not to be stuck inside an aberrant state while conflicts are in the process of being resolved. [0]: https://docs.jj-vcs.dev/latest/conflicts/ https://docs.jj-vcs.dev/latest/conflicts/
  • deleted 6mo ago
    [deleted]
  • dzaima 6mo ago
    In git if you, say, do some `git rebase -i`, edit some commit, continue the rebase, and hit a conflict, and realize you edited something wrong that caused the conflict, your only option is aborting the entire rebase and starting over and rebuilding all changes you did. In jj, you just have a descending conflict, and if you edit the past to no longer conflict the conflict disappears; kinda as if you were always in interactive rebase but at all points have the knowledge of what future would look like if you `git rebase --continue`d. Also really nice for reordering commits which can result in conflicts, but leaves descendants non-conflicting, allowing delaying resolving the conflicts after doing other stuff, or continuing doing some reordering instead of always starting from scratch as with `git rebase -i`.
• WCSTombs 6mo ago
  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.
  • NetOpWibby 6mo ago
    This should be the default. Nearly every time I see a complaint about git, someone comes through with a command like this. Is there a collection of similar tips that makes git better to use? If not, there should be.
• mentalgear 6mo ago
  > [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.
  • Retr0id 6mo ago
    Yes. There are many ways to instantiate a CRDT, and a trivial one would be "last write wins" over the whole source tree state. LWW is obviously not what you'd want for source version control. It is "correct" per its own definition, but it is not useful. Anyone saying "CRDTs solve this" without elaborating on the specifics of their CRDT is not saying very much at all.
  • mweidner 6mo ago
    You can think of the semantics (i.e., specification) of any CRDT as a function that inputs the operation history DAG and outputs the resulting user-facing state. However, algorithms and implementations usually have a more programmatic description, like "here is a function `(internal state, new operation) -> new internal state`", both for efficiency (update speed; storing less info than the full history) and because DAGs are hard to reason about. But you do see the function-of-history approach in the paper "Pure Operation-Based Replicated Data Types" [1]. [1] https://arxiv.org/abs/1710.04469 https://arxiv.org/abs/1710.04469
• alunchbox 6mo ago
  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.
  • aduwah 6mo ago
    The only reason I have not defaulted to jj already is the inability to be messy with it. Easy to make mistakes without "git add"
    • dzaima 6mo ago
      But you do have the op log, giving you a full copy of the log (incl. the contents of the workspace) at every operation, so you can get out of such mistakes with some finagling. You can choose to have a workflow where you're never directly editing any commit to "gain back autonomy" of the working copy; and if you really want to, with some scripting, you can even emulate a staging area with a specially-formatted commit below the working copy commit.
    • llyama 6mo ago
      You can be messy. The lack of an explicit staging area doesn't restrict that. `jj commit` gives the same mental model for "I want to commit 2 files from the 5 I've changed".
    • nchmy 6mo ago
      You're mistaken. I'm an absolute version control slob. JJ allows me to continue like that yet also collaborate with others. It tracks literally everything so I can not only split, squash, and rebase things to wherever they need to be, but can also rollback/restore/recover anything from either the repo-wide oplog or revision-specific evolog You really ought to dive in deeper. jjui makes it all vastly simpler
    • simonmic 6mo ago
      You can turn off the auto-tracking, and add your files manually.
• phtrivier 6mo ago
  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" ?
  • dkdbejwi383 6mo ago
    Or even just "the branch you're on" and "the branch being merged into yours"
• hahaddmmm12x 6mo ago
  [flagged]
• lasgawe 6mo ago
  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!
• hahaddmmm12x 6mo ago
  [flagged]
• a-dub 6mo ago
  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?
• hahaddmmm12x 6mo ago
  [flagged]
• socalgal2 6mo ago
  > [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 https://news.ycombinator.com/item?id=47359712
• monster_truck 6mo ago
  Not this again
• hahhhha500012 6mo ago
  [flagged]
• codemog 6mo ago
  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.
  • twsted 6mo ago
    Version control systems are more important than ever with AI.
• BlueHotDog2 6mo ago
  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
• bob1029 6mo ago
  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.
  • fn-mote 6mo ago
    It seems like in a reasonable sized org you should not be merging so often that “centralized locking … across time zones” should be an issue. Are people really merging that often? What is being merged? Doc fixes?
    • unit149 6mo ago
      [dead]
    • jsmith45 6mo ago
      The file locking approach is one used by centralized version control systems, and are mostly used in the everybody commits directly to trunk style of development. In those environments merging isn't much of a thing. (Of course this style also comes with other challenges, especially around code review, as it means either people are constantly commit unreviewed code, or you develop some other system to pre-review code, which can slow down the speed of checking things in.) This approach is actually fairly desirable for assets types that cannot be easily merged, like images, sounds, videos, etc. You seldom actually want multiple people working on any one file of those at the same time, as one or the other of their work will either be wasted or have to be re-done.
• sibeliuss 6mo ago
  Why must everyone preprocess their blog posts with ChatGPT? It is such a disservice to ones ideas.
  • alansaber 6mo ago
    Because writing is really hard.
• deleted 6mo ago
  [deleted]
• newsoftheday 6mo ago
  OK, I'll stick with git.
• nkmnz 6mo ago
  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?
  • AceJohnny2 6mo ago
    Eh. It's a matter of visible pain vs invisible pain. Developers are quite familiar with Merge Conflicts and the confusing UI that git (and SVN before it, in my experience) gives you about them. The "ours vs theirs" nomenclature which doesn't help, etc. This is something that VCSs can improve on, QED this post. Vs the scenario you're describing (what I call Logical Conflicts), where two changes touching different parts of the code (so it doesn't emerge as a Merge Conflict) but still breaking each other. Like one change adding a function call in one file but another change changing the API in a different file. These are painful in a different way, and not something that a simple text-based version control (which is all of the big ones) can even see. Indeed, CRDTs do not help with Logical Conflicts.
    • nkmnz 6mo ago
      Thank you for the clarification. I agree that the current state of the art to show conflicts _in the same part of the code_ is not sufficient, so any improvement with regard to that is welcome. Still, I'm more looking for solutions with the Logical Conflicts.
• gavinhoward 6mo ago
  Bram Cohen is awesome, but this feels a little bare. I've put much more thought into version control ([1]), including the use of CRDTs (search for "# History Model" and read through the "Implementing CRDTs" section). [1]: https://gavinhoward.com/uploads/designs/yore.md https://gavinhoward.com/uploads/designs/yore.md
  • AceJohnny2 6mo ago
    That's worth making a separate post! (and I recommend rendering it to HTML) But "bare" is part of the value of Cohen's post, I think. When you want to publicize a paradigm shift, it helps to make it in small, digestible chunks.
  • 63stack 6mo ago
    Is this the Bram Cohen who made bittorrent? There is surprisingly little information on this page.
    • vessenes 6mo ago
      Yes
    • esafak 6mo ago
      Yes, just look at his Github page.
• MattCruikshank 6mo ago
  For anyone who thinks diff / merge should be better - try Beyond Compare from Scooter Software.
• steveharing1 6mo ago
  Git is my first priority until or unless i see anything more robust than this one.
• barrkel 6mo ago
  I don't really get the upside of focus on CRDTs. The semantic problem with conflicts exists either way. You get a consistent outcome and a slightly better description of the conflict, but in a way that possibly interleaves changes, which I don't think is an improvement at all. I am completely rebase-pilled. I believe merge commits should be avoided at all costs, every commit should be a fast forward commit, and a unit of work that can be rolled back in isolation. And also all commits should be small. Gitflow is an anti-pattern and should be avoided. Long-running branches are for patch releases, not for feature development. I don't think this is the future of VCS. Jujutsu (and Gerrit) solves a real git problem - multiple revisions of a change. That's one that creates pain in git when you have a chain of commits you need to rebase based on feedback.
  • gzread 6mo ago
    People see that CRDTs have no conflicts and proclaim them as the solution to all problems, not seeing that some problems inherently have conflicts and either can't be represented by CRDTs at all, or that the use of CRDTs resolves conflicts in a way that's worse than if you actually thought about conflict resolution. E.g. that multiplayer text editor that interleaved characters from simultaneous edits.
  • IgorPartola 6mo ago
    I used to use rebase much more than merge but have grown to be more nuanced over the years: Merge commits from main into a feature branch are totally fine and easier to do than rebasing. After your feature branch is complete you can do one final main-to-feature-branch merge and then merge the feature branch into main with a squash commit. When updating any branch from remote, I always do a pull rebase to avoid merge commits from a simple pull. This works well 99.99% of the time since what I have changed vs what the remote has changed is obvious to me. When I work on a project with a dev branch I treat feature branches as coming off dev instead of main. In this case I merge dev into feature branches, then merge feature branches into dev via a squash commit, and then merge main into dev and dev into main as the final step. This way I have a few merge commits on dev and main but only when there is something like an emergency fix that happens on main. The problem with always using a rebase is that you have to reconcile conflicts at every commit along the way instead of just the final result. That can be a lot more work for commits that will never actually be used to run the code and can in fact mess up your history. Think of it like this: 1. You create branch foo off main. 2. You make an emergency commit to main called X. 3. You create commits A, B, and C on foo to do your feature work. The feature is now complete. 4. You rebase foo off main and have to resolve the conflict introduced by X happening before A. Let’s say it conflicts with all three of your commits (A, B, and C). 5. You can now merge foo into main with it being a fast forward commit. Notice that at no point will you want to run the codebase such that it has commits XA or XAB. You only want to run it as XABC. In fact you won’t even test if your code works in the state XA or XAB so there is little point in having those checkpoints. You care about three states: main before any of this happened since it was deployed like that, main + X since it was deployed like that, and main with XABC since you added a feature. git blame is really the only time you will ever possibly look at commits A and B individually and even then the utility of it is so limited it isn’t worth it. The reality is that if you only want fast forward commits, chances are you are doing very little to go back and extract code out of old versions a of the codebase. You can tell this by asking yourself: “if I deleted all my git history from main and have just the current state + feature branches off it, will anything bad happen to my production system?” If not, you are not really doing most of what git can do (which is a good thing).
• catlifeonmars 6mo ago
  Can we stop using line-oriented diffs in favor of AST-oriented diffs? Is it just lack of tooling, or is there something fundamentally better about line-oriented diffs that I’m missing? For the purpose of this question I’m considering line-oriented as a special case of AST-oriented where the AST is a list of lines (anticipating the response of how not all changes are syntactically meaningful or correct).
• Aperocky 6mo ago
  Outside of the merit of the idea itself, I thought I was going to look at a repository at least as complete as Linus when he released git after 3 weeks, especially with the tooling we had today. Slightly disappointed to see that it is a 470 line python file being touted as "future of version control". Plenty of things are good enough in 470 lines of python, even a merge conflict resolver on top of git - but it looks like it didn't want anything to do with git. Prototyping is almost free these days, so not sure why we only have the barest of POC here.
  • ithkuil 6mo ago
    It clearly says in the article that this is just a demo
    • mtndew4brkfst 6mo ago
      A demo as "the future of" something doesn't really resonate with me. It's like saying a melodic motif and a couple well-written lines of lyrics are "the future of" my new music career.
      • ithkuil 6mo ago
        I guess it depends on how you parse "the future of X". To me it sounds like "This is how I imagine the future of X", i.e. a preview of a possible future.
• merlindru 6mo ago
  I recently found a project called sem[1] that does git diffs but is aware of the language itself, giving feedback like "function validateToken added", "variable xyzzy removed", ... i think that's where version control is going. especially useful with agents and CI [1] https://ataraxy-labs.github.io/sem/ https://ataraxy-labs.github.io/sem/
• lowbloodsugar 6mo ago
  Araxis merge. Four views. Theirs, ours, base and “what you did so far in this damned merge hell”.
• hahhhha500012 6mo ago
  [flagged]
• echrisinger 6mo ago
  Has anyone considered a VCS that integrates more vertically with the source code through ASTs? IE if I change something in my data model, that change & context could be surfaced with agentic tooling.
  • conartist6 6mo ago
    That's me, with BABLR. Working on getting a beta release announced in the next few days.
• aggregator-ios 6mo ago
  What CRDT's solve is conflicts at the system level. Not at the semantic level. 2 or more engineers setting a var to a different value cannot be handled by a CRDT. Engineer A intended value = 1 Engineer B intended value = 2 CRDT picks 2 The outcome could be semantically wrong. It doesn't reflect the intent. I think the primary issue with git and every other version control is the terrible names for everything. pull, push, merge, fast forward, stash, squash, rebase, theirs, ours, origin, upstream and that's just a subset. And the GUI's. They're all very confusing even to engineers who have been doing this for a decade. On top of this, conflict resolution is confusing because you don't have any prior warnings. It would be incredibly useful if before you were about to edit a file, the version control system would warn you that someone else has made changes to it already or are actively working on it. In large teams, this sort of automation would reduce conflicts, as long as humans agree to not touch the same file. This would also reduce the amount of quality regressions that result from bad conflict resolutions. Shameless self plug: I am trying to solve both issues with a simpler UI around git that automates some of this and it's free. https://www.satishmaha.com/BetterGit https://www.satishmaha.com/BetterGit
  • jnsie 6mo ago
    > It would be incredibly useful if before you were about to edit a file, the version control system would warn you that someone else has made changes to it already or are actively working on it. In large teams, this sort of automation would reduce conflicts, as long as humans agree to not touch the same file. This would also reduce the amount of quality regressions that result from bad conflict resolutions. Bringing me back to my VSS days (and I'd much rather you didn't)
    • aggregator-ios 6mo ago
      I knew I should have put a trigger warning, because I was thinking of this as I was typing it. Sorry!
  • mbfg 6mo ago
    well, the mismatch here is widened by the fact that almost everyone it seems uses git with a central, prominent, visible, remote repository. Where as git was developed with the a true distributed vision. Now sure that truely distributed thing only becomes final when it reaches some 'central' repo, but it's quite a big different than we all do.
• ballsweat 6mo ago
  [dead]
• injidup 6mo ago
  I'm confused about what this solves. They give the example of someone editing a function and someone deleting the same function and claim that the merge never fails and then go on to demonstrate that indeed rightly the merges still fails. There are still merge markers in the sources. What is the improvement exactly?
  • galkk 6mo ago
    Yeah, the author fails to present his case even in the intro > A CRDT merge always succeeds by definition, so there are no conflicts in the traditional sense — the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails. This project works that out. It has clear contradiction. Crdt always succeed by definition, no conflicts in traditional sense so (rephrasing) conflicting changes are marked as conflicted. Emm, like in any other source control? In fact, after rereading that intro while writing that answer I start suspect at least smell of an ai writing.
    • fleebee 6mo ago
      The README of the repo offers a hint: > The code in this project was written artisanally. This README was not.
    • josephg 6mo ago
      The benefit of using a crdt for this is that you can get better merge semantics. Rebase and merge become the same thing. Commits can’t somehow conflict with themselves. You can have the system handle 2 non conflicting changes on the same line of code if you want. You can keep the system in a conflict state and add more changes if you want to. Or undo just a single commit from a long time ago. And you can put non text data in an crdt and have all the same merge and branching functionality.
• ballsweat 6mo ago
  Everyone should vibe code a VCS from scratch in their fave language. It’s an awesome weekend project, you can have fun visualizing commits in different ways (I’m experimenting with shaders), and importantly: This is the way forward. So much software is a wrapper around S3 etc. now is your chance to make your own toolset. I imagine this appeals more to DIYer types (I use Pulsar IDE lol)
• deleted 6mo ago
  [deleted]
• braidedpubes 6mo ago
  Do I have it right that it’s basically timestamp based, except not based on our clocks but one it manages itself? So as long as all updates have been sent to the server from all clients, it will know what “time” each character changed and be able to merge automatically. Is that it basically?
• xthe 6mo ago
  [dead]
• EGreg 6mo ago
  I remember I met Bram Cohen (of Bittorent fame!) around 15 years ago. Around that time is when I had started building web-based distributed collaborative systems, starting with Qbix.com and then spun off a company to build blockchain-based smart contracts through Intercoin.org etc. Anyway, I wanted to suggest a radical idea based on my experience: Merges are the wrong primitive. What organizations (whethr centralized or distributed projects) might actually need is: 1) Graph Database - of Streams and Relations 2) Governance per Stream - eg ACLs A code base should be automatically turned into a graph database (functions calling other functions, accessing configs etc) so we know exactly what affects what. The concept of what is “too near” each other mentioned in the article is not necessarily what leads to conflicts. Conflicts actually happen due to conflicting graph topology and propagating changes. People should be able to clone some stream (with permission) and each stream (node in the graph) can be versioned. Forking should happen into workspaces. Workspaces can be GOVERNED. Publishing some version of a stream just means relating it to your stream. Some people might publish one version, others another. Rebasing is a first-class primitive, rather than a form of merging. A merge is an extremely privileged operation from a governance point of view, where some actor can just “push” (or “merge”) thousands of commits. The more commits, the more chance of conflicts. The same problem occurs with CRDTs. I like CRDTs, but reconciling a big netsplit will result in merging strategies that create lots of unintended semantic side effects. Instead, what if each individual stream was guarded by policies, there was a rate limit of changes, and people / AIs rejected most proposals. But occasionally they allow it with M of N sign offs. Think of chatgpt chats that are used to modify evolving artifacts. People and bots working together. The artifacts are streams. And yes, this can even be done for codebases. It isnt about how “near” things are in a file. Rather it is about whether there is a conflict on a graph. When I modify a specific function or variable, the system knows all of its callers downstream. This is true for many other things besides coding too. We can also have AI workflows running 24/7 to try out experiments as a swarm in sandboxes, generate tests and commit the results that pass. But ultimately, each organization determines whether they want to rebase their stream relations to the next version of something or not. That is what I’m building now with https://safebots.ai https://safebots.ai PS: if anyone is interested in this kind of stuff, feel free to schedule a calendly meeting w me on that site. I just got started recently, but I’m dogfooding my own setup and using AI swarms which accelerates the work tremendously.
• theknarf 6mo ago
  You can't use CRDTs for version control, having conflicts is the whole point of version control. Sometimes two developers will make changes that fundamentally tries to change the code in two different ways, a merge conflict then leaves it up to the developer who is merging/rebasing to make a choice about the semantics of the program they want to keep. A CRDT would just produce garbage code, its fundamentally the wrong solution. If you want better developer UX for merge conflicts then there are both a bunch of tooling on top of Git, as well as other version control systems, that try to present it in a better way; but that has very little to do with the underlaying datastructure. The very fact that cherry-picking and reverting becomes difficult with this approach should show you that its the wrong approach! Those are really easy operations to do in Git.
  • tbrownaw 6mo ago
    > You can't use CRDTs for version control You misunderstand what is being proposed. Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy. . Consider for example if you want to track and merge scalar values. Maybe file names if you track renames, maybe file properties if you're not just using a text listing (ie .gitattributes) for that, maybe file content hash to decide whether to actually bother running a line-based merge. One approach is to use what Wikipedia says is called an OR-set[1], with the restriction that a commit can only have a single unique value; if it was previously in the set then it keeps all the same tags, if it wasn't then it gets a new tag. That restriction is where the necessity of conflict resolution comes in. It doesn't have to be part of the underlying algorithms, just the interface with the outside world. [1] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#OR-Set_(Observed-Remove_Set) https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...
    • Retr0id 6mo ago
      If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?
• astrostl 6mo ago
  Disagree. We all are — or should be — Linux kernel developers. What's more, we should align to a specific and singular VCS worldview informed by BitKeeper, which no longer exists, whether or not we used it. Therefore Git. Thank you for your attention to this matter!
  • simultsop 6mo ago
    You sound more like a DOS dev instead of linux.
• deleted 6mo ago
  [deleted]
• Ferret7446 6mo ago
  I'm pretty sure jujutsu already does this, and it's interopable with git
• deleted 6mo ago
  [deleted]
• nailer 6mo ago
  You’re still treating code as text which it isn’t (in the same way you wouldn’t treat JSON as text) it’s actually more like an AST. Jujutsi (jj) does that. And it’s git compatible.
  • dcre 6mo ago
    I love jj and think virtually every git user should switch to it, but I don't think it treats text as an AST. What do you mean?
    • nailer 6mo ago
      Ugh you're right. There was a new AST-based version control system that came out a month ago and I couldn't remember the name. I asked an LLM what the name was and repeated the answer the LLM gave me without checking (facepalm). I may have been thinking of https://github.com/gritzko/librdx/tree/master/be https://github.com/gritzko/librdx/tree/master/be
      • WolfeReader 6mo ago
        Thanks for the correct link! AST-based version control sounds like a great idea.
  • 12_throw_away 6mo ago
    No, it doesn't.
    • nailer 6mo ago
      https://news.ycombinator.com/item?id=47488270 https://news.ycombinator.com/item?id=47488270
• mweidner 6mo ago
  I'm surprised to see the emphasis on tracking lines of text, which ties in to the complexity of merge vs merge-the-other-way vs rebase. If we are committed to enhancing the change history, it seems wiser to go all in and store high-level, semantically-meaningful changes, like "move this code into an `if` block and add `else` block ...". Consider the first example in the readme, "Left deletes the entire function [calculate]. Right adds a logging line in the middle". If you store the left operation as "delete function calculate<unique identifier>" and the right operation as "add line ... to function calculate", then it's obvious how to get the intended result (calculate is completely deleted), regardless of how you order these operations. I personally think of version control's job not as collaborating on the actual files, but as collaborating on the canonical order of (high-level) operations on those files. This is what a branch is; merge/rebase/cherry-pick are ways of updating a branch's operation order, and you fix a conflict by adding new operations on top. (Though I argue rebase makes the most sense in this model: your end goal is to append to the main branch.) Once you have high-level operations, you can start adding high-level conflict markers like "this operation changed the docs for function foo; flag a conflict on any new calls to foo". Note that you will need to remember some info about operations' original context (not just their eventual order in the main branch) to surface these conflicts.
• philwelch 6mo ago
  Regardless of the merits of CRDT's, I'm just glad someone is finally trying to create a new version control system. Everyone loves to complain about Git but nobody's actually tried to move beyond it in two decades.
  • Nursie 6mo ago
    There are those of us who remember the before-times, who I think are in general just happy we have git. Having lived through sccs, pvcs, SourceSafe, Clearcase and svn (among others), the introduction of lightweight, sane branching, merging, rebasing etc was a revelation. Yes, there are still things that an adept could do with some of those other systems that git doesn't make easy. For example we have the holy war between those who demand a git repo has a clean history vs those who would rather a revision control system actually stores revision history and forms a record of what really happened. In Rational ClearCase you would use a different config specification depending on your task to programatically select visibility, and hey presto, you have both views available. (Not that I would wish ClearCase on my worst enemy these days, those config specs were a language in themselves and the amount of times people would get in trouble with them was a real drag, and that's only one of the myriad downsides.) Then git came along and did away with so much of that complexity that I imagine there are legions of us who think it's good enough (TM) that version control is more or less a solved problem and nothing irks us enough to seek out alternatives.
    • philwelch 6mo ago
      I can definitely relate to that, and I'm actually quite fond of git myself. I just never expected that people would stop trying to make a better version control system. That's not entirely fair, a lot of work has been invested in Pijul and Fossil, but I would have expected much more interest in alternatives. I remember all of the reasons Git was so new and exciting at the time, but now it feels like we're all locked into it, not out of any deliberate attempt at vendor lockin but out of complacency, and because fewer and fewer of us still remember a time that it felt possible to invent a better version control system.
      • 6mo ago
• KPGv2 6mo ago
  I've tested out jj a bit, and doesn't it solve the issues presented at the link already? I don't work on a team where I need VC better than git, so I just stick with it for my own private use, but I did test jj out of curiosity, and I could've sworn this is basically the same pitch as switching to jj (but for the CRDT under the hood).
• periodjet 6mo ago
  Does this mean he’s given up on Chia?
• danpalmer 6mo ago
  I'm struggling to understand the problem this solves for me. I can see in the abstract why this might be useful, but in practice I don't see the problems. For me, jj represents a massive step forward from git in terms of usability, usefulness, and solving problems I actually have. I think the next step forward for version control would be something that works at a lower level, such as the AST. I'd love to see an exploration of what versioning looks like when we don't have files and directories, and a piece of software is one whole tree that can be edited at any level. Things like LightTable and Dark have tried bits of this, it would be good to see a VCS demo of that sort of thing.
  • conartist6 6mo ago
    It is coming. Had to build a whole new system of parsers.
• pbw 6mo ago
  This sounds good, but I wonder if AI has changed the calculus on conflict resolution. It can not only chase down the conflicting changes, but also read those commit messages and PRs to divine intent. It might be that git is "good enough," given we have AI.
• ReaLNero 6mo ago
  Thank you. This sounds like a great approach! I’ve also been surprised at the mechanical nature that git resolves conflicts in, and the loss of intent when auto-merging.
• Androider 6mo ago
  I've had really good success lately with having Claude Code resolve conflicts, to the point that I don't see myself doing manual resolutions going forward. Set git.conflictStyle to zdiff3 and ask Claude to resolve the conflict, or even better, complete the entire rebase for you. A quick diff sanity check against the merge base of the result takes just a few seconds.
  • mememememememo 6mo ago
    Thanks literally just used this!
• suralind 6mo ago
  Guys, there’s a tool called mergiraf[1] that does wonders. I don’t remember my last rebase [1]: https://mergiraf.org/ https://mergiraf.org/
  • senfiaj 6mo ago
    Yeah, I also thought that a semantic merge is the best solution. It would be nice if it could be extended with custom formats such as sqlite.
• csomar 6mo ago
  I am working on merge conflicts tool[1], so this area is of interest to me. But I fail to see the points of the author. In the first example he gave, git will actually give you three blobs: our, their and ancestor. The ancestor should have the missing information from his example and using code diffs[2], you can see what happened at each blob. Essentially, his blob is a single view of the 3 blobs merged together. Could be useful on the terminal, but if you are using a visual tool, a 3-way diff is always better. > merges never fail I am not sure what never fail means here. > Conflicts are informative, not blocking. The merge always produces a result. What does this even mean? You merge first and review later? And then other contributor just build on top of your main branch as you decided you want to change your selection? If you want a smarter merge conflict tool, the one I am enthusiastic about today is Mergiraf: https://codeberg.org/mergiraf/mergiraf https://codeberg.org/mergiraf/mergiraf 1: https://codeinput.com/products/merge-conflicts https://codeinput.com/products/merge-conflicts 2: https://codeinput.com/products/merge-conflicts/demo https://codeinput.com/products/merge-conflicts/demo
• donatj 6mo ago
  > One idea I’m particularly excited about: rebase doesn’t have to destroy history. I guess I don't understand why not just merge at that point? The point of rebadge is to destroy history...
• modeless 6mo ago
  > the key insight is that changes should be flagged as conflicting when they touch each other Not really. Changes should be flagged as conflicting when they conflict semantically, not when they touch the same lines. A rename of a variable shouldn't conflict with a refactor that touches the same lines, and a change that renames a function should conflict with a change that uses the function's old name in a new place. I don't think I would bother switching to a new VCS that didn't provide some kind of semantic understanding like this.
• yalvhe2009 6mo ago
  [flagged]
• yalvhe2009 6mo ago
  [flagged]
• chungy 6mo ago
  The merge conflict syntax and "doesn't destroy history" both sound exactly like what Fossil does. (Fossil is at https://fossil-scm.org/ https://fossil-scm.org/) Just a trivial example here: lorem ipsum <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<< (line 2) dolor sit amet, ####### SUGGESTED CONFLICT RESOLUTION follows ################### consectetur adipiscing elit ||||||| COMMON ANCESTOR content follows ||||||||||||||||||||||||| (line 2) ======= MERGED IN content follows =============================== (line 2) consectetur adipiscing elit >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
• qsera 6mo ago
  I think this was something that was waiting for something like LLMs to happen to be solved. Why aren't AI companies touting "zero-shot"ing huge merge conflicts being resolved by LLMs..
  • adastra22 6mo ago
    Have you tried this? It would be a nightmare. The LLM wold "solve" the merge conflict by eliminating the code.
    • qsera 6mo ago
      But that should make the builds or some tests to fail no? I think we can consider it as a first approximation and proceed to a manual review. It should be a lot easier than manually resolving the difficult merge..
      • adastra22 6mo ago
        That’s solved by disabling or removing those tests. I have tried this. It does’t work.
• toomim 6mo ago
  CRDTs actually have a long history in version control. - The original 1977 version control system, SCCS, was a CRDT: https://braid.org/meeting-60/sccs-is-a-time-collapse - It called its data structure a 'weave" - Brahm's old project "Codeville" used a weave for version control - But then git blew up in popularity. - The project "DARCS" tried to make a robust "theory of patches," and eventually led to the development of Pijul - Pijul is a VCS that is a CRDT: https://pijul.org
• twinpost_rules 6mo ago
  [dead]
• jes5199 6mo ago
  This is just CRDT merges and better diffs?? I think the future of version control is much, much weirder than this. Like if you have CRDTs why not have ephemeral branches with real-time collaborative editing and live CI as you type
• forrestthewoods 6mo ago
  I hate Git. I think it is mediocre at absolute best. But nothing in this article is in my top 10. So this doesn’t really do anything for me. All I really want is support for terabytes scale repo history with super fast, efficient, sparse virtual clones. And ideally a global cache for binary blobs with copy-on-write semantics. Which is another way to say I want support for large binary files, and no GitLFS is not sufficient.
• latand666 6mo ago
  This sounds very promising, liked the idea Is there a CLI like git CLI? Have read the readme but didn’t quite get how to use
• latand666 6mo ago
  Have you also thought about multiple staging levels/layers? Sometimes I don’t want to commit the work, just to review the AI work piece by piece, moving to the next staging level. I guess I can do that with plain commits as well and then rewrite history when I need, but I think having multiple staging levels would be more developer friendly especially in the era of AI coding
• QuiCasseRien 6mo ago
  I will look at it, it seems interesting. However, i hope a better ending than Pyjul (https://pijul.org/ https://pijul.org/). I'm no longer waiting for it whereas everything sound awesome : quite no more merge conflict and patches order free. So sad it's still not production ready.
• PunchyHamster 6mo ago
  At this point if your VCS isn't a layer above git plumbing, nobody gonna waste time using it. Especially if the improvements are minor enough that it could be reasonably just a wrapper and still have 90% of the improvements. > Two opaque blobs. You have to mentally reconstruct what actually happened. Did you not discover what git diff does ? It's clearer than the presented improvement ! Plenty of 3 way merge tools supported by git too, sure, it's external tool but it's adding one tool rather than upending the workflow > Conflicts are informative, not blocking. The merge always produces a result. Conflicts are surfaced for review when concurrent edits happen “too near” each other, but they never block the merge itself. And because the algorithm tracks what each side did rather than just showing the two outcomes, the conflict presentation is genuinely useful. Git merge cache (git rerere) is good enough. Only problem is that it isn't shared but that could be possibly done within git format itself if someone really wanted to
  • gavinhoward 6mo ago
    > At this point if your VCS isn't a layer above git plumbing, nobody gonna waste time using it. Probably true, but it's a shame because there are better ways of storing and processing the data, ways that natively handle binary files, semantics, and large files without falling over.
• teeray 6mo ago
  > Conventional rebase creates a fictional history where your commits happened on top of the latest main This is not fiction though. If someone added a param to the functions you’re modifying on your branch, rebasing forces you to resolve that conflict and makes the dependency on that explicit and obvious.
• alkonaut 6mo ago
  The most infuriating part about git's default behavior is that it's so ignorant about what actual reality users live in. For example: when merging or rebasing it's really important to know what I did myself, vs what someone else did. Yet it has a really opaque left/right or mine/theirs representation which even switches meaning depending on the operation you are doing. This isn't even a fundamental diff/patch issue it's just that git shrugs and assumes you want to perform some abstract operation on a DAG of things rather than, you know, rebase your code onto that of your colleagues.
• ata-sesli 6mo ago
  The core separation line here seems to be Snapshot vs. Weave. Git treats history as a path between states, but Manyana treats the state as the history. Since the weave grows with every line ever written, how do you handle "tombstone" (deleted data) bloat? In a decade-old repo with high churn, does the metadata overhead for a single file eventually make it unmanageable compared to Git’s "forgetful" snapshotting?
• gitmwnkdkc 6mo ago
  People are still having a problem with distributed version control, because some people want to force ”the server’s” history down the throats of all coworkers. This can not be solved with tech, it’s a people problem. Conflicts between branches is only a symptom of conflicts between people. Some want individual freedom to manage branches in whatever way (and these people are usually very open to other people managing branches in another way), but some people are against this freedom and thinks branches should be managed centrally by an authority (such people usually have a problem working on their own).
• guytv 6mo ago
  I just let claude do all conflict resolution for me. code conflicts are a solved problem.
• mpalmer 6mo ago
  This sounds more like the present of version control in the form of Jujutsu, which already supports 3-way merges and history-preserving rebases, and does so with data structures that are trivially representable in a standard git repo. > What it is is a proof that CRDT-based version control can handle the hard UX problems and come out with better answers than the tools we’re all using today — and a coherent design for building the real thing. No such thing is "proven". You have not proven superiority to the state of the art with 400 lines of Python. The LLM you used to draft this blog post is making your solution out to be far more than it is at this point.
• i18nagentai 6mo ago
  [flagged]
• gigatexal 6mo ago
  how are CRDTs magic wrt to merges and conflicts? im happy to see new entrants into the space. I think I'm a git beginner+. I know enough to be productive and am no longer fearful of it... and I even train up my coworkers on it and help them out of binds... but I am not an expert by any means and still sometimes resort to radical things to get me through some problem I've put myself into.
• metmac 6mo ago
  https://loro.dev/ https://loro.dev/ Relevant. Loro a lovely CRDT library, explored implementing VCS semantics with CRDTs.
• m12k 6mo ago
  I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual changes. I used to think this would require a new version control system that encodes the semantics of the changes in the commits, in order to have them available at merge-time. But these days, it seems much more realistic to stick to git, but loop in LLMs when merging, to re-create the semantics from the textual changes.
  • bilekas 6mo ago
    This is more than just a version control though, they only thing any VC uses that's important is the diff and the timestamps, you would be adding in project context awareness which is a whole other thing. I'm sure there are smarter people than me who could create some hooks to automagically update those references on merge/rebase though. Not sure I would pay a whole LLM each time personally.
  • WolfeReader 6mo ago
    Darcs did this decades ago with the "replace" command. It's not a legitimate semantic replacement, though - it's more just telling your VCS to do a find/replace.
    • gnufx 6mo ago
      As far as I remember, that's just because only the find/replace was implemented, and it could have more sophisticated (semantic?) features.
  • cush 6mo ago
    > I renamed a method, while someone else concurrently added another call to that This is the most common use case for any compiler or linter
• blueplanet200 6mo ago
  Reminds me of this article from way back, "A look back: Bram Cohen vs Linus Torvalds" Of significance here because the resolution strategy from merges was deeply at the disagreement between Bram and Linus. https://web.archive.org/web/20110728005409/http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php https://web.archive.org/web/20110728005409/http://www.wincen...
  • jancsika 6mo ago
    It's worth reflecting on just how many VCS data (or pain) points Linus had ingested right before writing git. Probably more than anyone in FOSS outside of maybe a few Debian devs. Add to that his experience successfully using Bitkeeper prior to that and you can easily see why git is where it is in 2026. Given a large enough amount of data/pain, designing/optimizing to attack specific, known pain points always beats trying to solving a more general problem elegantly. I mean, kudos to whoever decided Zoom clients with shoddy connections should buffer then race back to realtime at 1.x - 2x speed (can't remember exactly how fast it goes-- perhaps it's dynamic?). One could come up with 1000 toy examples of where that breaks (music lesson, drama class, etc.), or just implement it and save a gazillion people gazillion hours of repeating themselves in boring meetings. Edit: clarification
• tinfoilcondom 6mo ago
  Why are some projects like “artifact” marked Dead here while others like “fossil” are promoted in the comments? What counts as advertise vs spam? They seem like nearly identical posts and both projects really exist, separate authors. Why are random posts marked Dead on this platform? Seems like outright censorship
• itsnexis 6mo ago
  [flagged]
  • cweagans 6mo ago
    > it makes history a lie that eventually collapses under its own weight in large teams Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame. My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specifics until your work is merged into a shared branch that we all understand to be the canonical representation of the software we're working on.
    • idoubtit 6mo ago
      I'm not the GP, but I've seen "rebase lies" in the wild. Suppose a file contains a list of unique strings, one by line. A commit on a feature branch adds an element to the list. Later on, the branch is rebased on the main branch and pushed. But the main branch had added the same element at another position in the list. Since there was a wide gap between the two positions, there was no conflict in Git's rebase. So the commit in the feature branch breaks the unicity constraint of the list. For someone that pulled the feature branch, the commit seems stupid. But initial commit was fine, and the final (rebased) commit is a lie: nobody created a duplicate item.
      • cweagans 6mo ago
        Thanks for that. I'm definitely familiar with that kind of situation, but what I'm not seeing is how that leads to history "collapsing under its own weight" in larger teams. That seems like a relatively straightforward rebase error that is easily corrected. (Also, if it is important for that list to only include unique items and you were able to merge it anyway, maybe that also reveals a gap in the test suite?)
    • cxr 6mo ago
      > Can you please elaborate on this? You're replying to an LLM-powered comment generator.
• brahimmami 6mo ago
  Brahim 1462163579
• cush 6mo ago
  The single trivial example is not convincing
• r3c0nc1l3r 6mo ago
  This is a cool idea! These days, I think that all new version control solutions now have to be examined in the light of how well they work with with coding agents. In that light, the CRDT merging here is interesting, as it allows history preservation in scenarios that would otherwise be destructive. This way, agents can use worktrees with much less hassle as squash, rebase, merge become more straightforward.
• Koshkin 6mo ago
  What's currently missing from the automatic conflict resolution is intelligence. The AI doing merges is the future.
• mdnahas 6mo ago
  This is a bad idea. I spent a lot of time thinking about git’s snapshot system vs. merge-based system that were promoted by functional programming fans. Auto merging systems are bad for a good reason: because we care about features, which are a property of snapshots not diffs. If you have a diff that adds a button and a diff that turns existing button blue, the merge of those diffs doesn’t add a button and have all button blue. Because it may not make the new button blue. Features like “all buttons are blue” are properties of snapshots. Snapshot based revision control, like git, it better for that reason.
• gcr 6mo ago
  Here's how jj handles this situation. I made `foo.py` in ymywkkys, the base change. I added the logging line in ystzrmlq. For the other branch, I ran `jj edit ym` and changed the function body to just `return 42` in vxuxqtnu. Finally, I generate the merge commit with `jj new ym vx`. The graph looks like this: @ qttvouvl gcr@hackerne.ws 2026-03-24 10:02:56 (conflict) ├─╮ (empty) Some merge commit │ ○ ystzrmlq gcr@hackerne.ws 2026-03-24 10:02:54 │ │ Add logging line ○ │ vxuxqtnu gcr@hackerne.ws 2026-03-24 10:02:54 ├─╯ Just return 42 ○ ymywkkys gcr@hackerne.ws 2026-03-24 10:02:49 │ Base function ◆ zzzzzzzz root() 00000000 In jj, merges and rebases always succeed, but they may generate conflicts which are first-class objects in the repository alongside files, changes, directories, and so on. Having a structured way of representing conflicts allows for a more structured vocabulary. For instance, "conflict markers" don't live in the file itself, they're just rendered out to the working copy whenever the working copy gets updated. I personally find this diff harder to read than the proposed format in the post, but the same information is there: def calculate(x): <<<<<<< conflict 1 of 1 +++++++ vxuxqtnu "Just return 42" return 42 %%%%%%% diff from: ymywkkys "Base function" \\\\\\\ to: qttvouvl "Some merge commit" (rebased revision) a = x * 2 + logger.debug(f"a={a}") b = a + 1 return b >>>>>>> conflict 1 of 1 ends
  • yencabulator 6mo ago
    You might like [ui] conflict-marker-style = "snapshot" It's pretty close to what's in the article (while including more real-world useful information, being part of a fully-functional VCS and all). https://docs.jj-vcs.dev/latest/conflicts/#conflict-markers https://docs.jj-vcs.dev/latest/conflicts/#conflict-markers Personally, I'm a bit torn; the snapshot style doesn't draw my attention to the actually-changed lines.