Discussion
Bram’s Thoughts
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.
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.
simonw: I hadn't heard of Pijul. My first search took me tohttps://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 had a commit last month.... and of course it is, because Pijul uses Pijul for development, not Git and GitHub!
idoubtit: The canonical website is https://pijul.org. The homepage has a link to the pijul source repository.
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.
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.
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.
hungryhobbit: 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.
recursivecaveat: 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.
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.
rectang: I agree. Nevertheless I wonder if this approach help with certain other places where Git sometimes struggles, such as whether or not two commits which have identical diffs but different parents should be considered equivalent.In the general case, such commits cannot be considered the same — consider a commit which flips a boolean that one branch had flipped in another file. But there are common cases where the commits should be considered equivalent, such as many rebased branches. Can the CRDT approach help with `git branch -d BRANCH`?
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
crote: 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.
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.
miloignis: The rest of the article shows exactly how a CRDT is a sound base for a version control system, with "conflicts" and all.
mentalgear: Looks like vscode diff view .
TacticalCoder: 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: What tool do you use? Does Magit support it natively?
jwilliams: Indeed. And plenty of successful merges end up with code that won't compile.FWIW I've struggled to get AI tools to handle merge conflicts well (especially rebase) for the same underlying reason.
codethief: > I hadn't heard of PijulI'm surprised! Pijul has been discussed here on HN many, many times. My impression is that many people here were hoping that Pijul might eventually become a serious Git contender but these days people seem to be more excited about Jujutsu, likely because migration is much easier.
simonw: Looks like it makes the homepage only once or twice a year (using points>50 as a proxy for that), had more buzz around five years ago: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
skydhash: 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.
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.
layer8: One solution is to decompose your code into modules with stable interfaces and reference them as versioned dependencies.
roryokane: Did you know that VS Code added support for the same four-pane view as p4merge years ago? I used p4merge as my merge tool for a long time, but I switched to VS Code when I discovered that, as VS Code’s syntax highlighting and text editing features are much better than p4merge’s.I also use the merge tool of JetBrains IDEs such as IntelliJ IDEA (https://www.jetbrains.com/help/idea/resolve-conflicts.html#r...) when working in those IDEs. It uses a three-pane view, not a four-pane view, but there is a menu that allows you to easily open a comparison between any two of the four versions of the file in a new window, so I find it similarly efficient.
conradludgate: My understanding of the way this is presented is that merges don't _block_ the workflow. In git, a merge conflict is a failure to merge, but in this idea a merge conflict is still present but the merge still succeeds. You can commit with conflicts unresolved. This allows you to defer conflict resolution to later. I believe jj does this as well?Technically you could include conflict markers in your commits but I don't think people like that very much
rightbyte: > You can commit with conflicts unresolved.True but it is not valid syntax. Like, you mean with the conflict lines?
ozten: They should mirror on GitHub for marketing purposes
nozzlegear: > 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.
