The future of version control • Hacker News Board

Re: The future of version control

#271

Post by skydhash » Mon, Mar 23, 2026, 3:12 AM UTC

josephg wrote: post #201

sroussey wrote: post #180

Earlier quoted context omitted.

In theory, maybe. In practice… last write wins (LWW) is a CFDT operator, so replace every mention of CRDT with LWW and issues will more obvious. Really though, the problem with merges is not conflicts, it’s when the merged code is wrong but was correct on both sides before the merge. At least a conflict draws your attention. When I had several large (smart but young) teams merging left and right this would come up an…

> In practice… last write wins (LWW) is a CFDT operator, so replace every mention of CRDT with LWW and issues will more obvious. Yeah. A lot of people are also confused by the twin meanings of the word "conflict". The "C" in CRDT stands for "Conflict (free)", but that really means "failure free". Ie, given any two concurrent operations, there is a well defined "merge" of the two operations. The merge operation can't…

> CRDTs have strictly more information about whats going on than Git does. At worst, we should be able to remake git on top of CRDTs. At best, we can improve the conflict semantics.

That is a worthwhile goal, but remember that code is just a notation for some operation, it's not the operation itself (conducted by a processor). Just like a map is a description of a place, not the place itself. So semantics exists outside of it and you can't solve semantics issue with CRDTs.

As code is formal and structured, version control conflict is a signal, not a nuisance. It may be crude, but it's like a canari in a mine. It lets you know that someone has modified stuff you've worked on in your patch. And then it's up to you to resolve the probable semantics conflicts.

But even if you don't have conflicts, you should check your code after a synchronization as things you rely on may have changed since your last one.

Re: The future of version control

#272

Post by otherayden » Mon, Mar 23, 2026, 3:23 AM UTC

ktm5j wrote: post #70

roryokane wrote: post #66

Earlier quoted context omitted.

Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" ( https://git-scm.com/docs/git-config#Documentation/git-config... ). If you do that, Git’s conflict markers show the base version as well: >>>>>> right With this configuration, a developer reading the raw conflict markers could infer the same information provided by Manyana’s conflict markers: that the right side added…

I'm on my phone right now so I'm not going to dig too hard for this, but you can also configure a "merge tool" (or something like that) so you can use Meld or Kompare to make the process easier. This has helped me in a pinch to work out some confusing merge conflicts.

Huge meld fan here, recommended by a professor about a year ago. Game changer

Re: The future of version control

#273

Post by gwerbin » Mon, Mar 23, 2026, 3:25 AM UTC

skydhash wrote: post #267

gwerbin wrote: post #240

Earlier quoted context omitted.

Git leaks a lot of implementation details into its UX. Rebasing is meant to be equivalent to checking out the "base" branch and cherry picking commits onto it. Therefore "ours" during a rebase is the base branch. The meaning of "ours" and "theirs" is always the same, but the "base" of the operation is reversed compared to what you might be used to during merge. Rebasing can be confusing and hard and messy, but once I…

Also git store (almost?) all its operations in the reflog. They have identifier like commits so you can reset to them and restore the original state of the working directory (mostly after an automatic rebase gone wrong).

That's the thing, they're not "like commits", they are the actual original commits. It's a history of where the HEAD ref used to be. Eventually those commits will be pruned out of the tree if/when the reflog expires because there is nothing left pointing to them. But otherwise they are normal commits.

Re: The future of version control

#274

Post by qsera » Mon, Mar 23, 2026, 3:28 AM UTC

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..

Re: The future of version control

#275

Post by toomim » Mon, Mar 23, 2026, 3:44 AM UTC

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

Re: The future of version control

#276

Post by toomim » Mon, Mar 23, 2026, 3:49 AM UTC

theknarf wrote: post #164

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 wron…

Pijul does both. It's a VCS, that is a CRDT, that preserves conflicts until a human resolves them.

Look it up: https://pijul.org

It also makes cherrypicking and rebasing wayyyy easier. You can actually add or remove any set of patches, at any time, on any peer. It's a dramatic model shift -- and is awesome.

Re: The future of version control

#277

Post by twinpost_rules » Mon, Mar 23, 2026, 4:02 AM UTC

[dead]

Re: The future of version control

#278

Post by shubhamjain » Mon, Mar 23, 2026, 4:45 AM UTC

theknarf wrote: post #164

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 wron…

I would like to point out that Bram Cohen seems to be obsessed with “better merges” and had a verbal spat with Linus on Git when it was just taking off (2007).

https://news.ycombinator.com/item?id=8118817

It’s pretty weird that he has gone back to the same idea without understanding why Git’s approach is better. I would say VCS is largely a solved problem. You can simplify a few things here and there, maybe improve support for binaries and few other things, but that’s almost on the top of existing systems. The foundation is rock solid, so it doesn’t sound very sensible to attempt something from ground up.

Re: The future of version control

#279

Post by Nursie » Mon, Mar 23, 2026, 5:02 AM UTC

philwelch wrote: post #205

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.

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.

Re: The future of version control

#280

Post by adastra22 » Mon, Mar 23, 2026, 5:02 AM UTC

simonw wrote: post #199

nicoty wrote: post #174

Earlier quoted context omitted.

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?

SQLite does it despite using Fossil - their mirror is at 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.

Git is not a protocol, it is a data format. That only makes sense when your VCS system is similar enough to git to easily allow converting between the two representations.