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.
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.<p>[1]: <a href="https://github.com/samoshkin/vim-mergetool" rel="nofollow">https://github.com/samoshkin/vim-mergetool</a>
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.<p>I assume the proposed system addresses it somehow but I don't see it in my quick read of this.
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.<p>In the general case, those 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`?
They address this; it's not that they don't fail, in practice...<p>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.
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.
This
I think something like this needs to be born out of analysis of gradations of scales of teams using version control systems.<p>- What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts?<p>- What do teams of 1, 10, 100, 1k, etc care the most about?<p>- How does the modern "agent explosion" potentially affect this?<p>For example, my experience working in the 1-100 regime tells me that, for the most part, <i>the kind of merge conflict</i> 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.<p>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.<p>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.
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.<p>Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper).<p>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.<p>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.<p>I like that Bram hasn’t let go of the problem, and is still trying out new ideas in the space.
The key insight in the third sentence?<p>> ... CRDTs for version control, which is long overdue but hasn’t happened yet<p>Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it.<p>Not that Bram is not one of those, but the post reads like you all know what.
I hadn't heard of Pijul. My first search took me to<a href="https://github.com/8l/pijul" rel="nofollow">https://github.com/8l/pijul</a> which hasn't been updated in 11 years, but it turns out that's misleading and the official repo at <a href="https://nest.pijul.com/pijul/pijul" rel="nofollow">https://nest.pijul.com/pijul/pijul</a> had a commit last month.<p>... and of course it is, because Pijul uses Pijul for development, not Git and GitHub!
> I hadn't heard of Pijul<p>I'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.
The canonical website is <a href="https://pijul.org" rel="nofollow">https://pijul.org</a>. The homepage has a link to the pijul source repository.
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.
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.
Overcoming network effects cannot be the goal; otherwise, work will never get done.<p>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.
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.
Interesting idea. While conflicts can be improved, I personally don't see it as a critical challenge with VCS.<p>What I do think is the critical challenge (particularly with Git) is scalability.<p>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.<p>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.
This thing is really short. <a href="https://github.com/bramcohen/manyana/blob/main/manyana.py" rel="nofollow">https://github.com/bramcohen/manyana/blob/main/manyana.py</a> 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.
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.
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.
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.
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. <a href="https://en.wikipedia.org/wiki/Bram_Cohen" rel="nofollow">https://en.wikipedia.org/wiki/Bram_Cohen</a><p>It's not the same as capturing it, but I would also note that there are a wide <i>wide</i> 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 (<a href="https://news.ycombinator.com/item?id=31075608">https://news.ycombinator.com/item?id=31075608</a>), including a <i>fantastic</i> incredibly wide ranging round up of merge tools (<a href="https://www.eseth.org/2020/mergetools.html" rel="nofollow">https://www.eseth.org/2020/mergetools.html</a>).<p>However/alas git 2.35's (2022) <i>fabulous</i> zdiff3 doesn't seems to have any big discussions (<a href="https://www.ductile.systems/zdiff3/" rel="nofollow">https://www.ductile.systems/zdiff3/</a> <a href="https://news.ycombinator.com/item?id=39428960">https://news.ycombinator.com/item?id=39428960</a>).