Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of version control

bramcohen.com

Post reply on HN
Print view View original

281–290 of 407 posts

Re: The future of version control

#281

Post by adastra22 »

verdverm wrote: post #218
simonw wrote: post #199

Earlier quoted context omitted.

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.

Similarly, CUE uses Gerrit and has two way sync. If you are building a VCS today, git interop is a must.

What if the whole point of your VCS is that it its core data structure is nothing like git's at all?

Re: The future of version control

#282

Post by adastra22 »

rbsmith wrote: post #90
ZoomZoomZoom wrote: post #4

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.

Do you use Pijul? From time to time, I do a 'pijul pull -a' into the pijul source tree, and I get a conflict (no local work on my part). Is there a way to do a tracking update pull? I didn't see one, so I toss the repo and reclone. What works for you in tracking what's going on there?

From time to time I get curious about Pijul, attempt to pull the Pijul repo from the nest, and encounter a no-workaround-possible bug in the network sync. I have never been able to do a fresh clone of Pijul.

It is very hard to take a project like this seriously.

Re: The future of version control

#283

Post by adastra22 »

mikey-k wrote: post #238
procaryote wrote: post #181

Earlier quoted context omitted.

What kind of scalability issues have you had with git? Is it because of a monorepo?

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…

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.

Re: The future of version control

#284

Post by adastra22 »

qsera wrote: post #274

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

Have you tried this? It would be a nightmare. The LLM wold "solve" the merge conflict by eliminating the code.

Re: The future of version control

#285

Post by jes5199 »

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

Re: The future of version control

#286

Post by theK »

furyofantares wrote: post #71
rightbyte wrote: post #59

Earlier quoted context omitted.

> You can commit with conflicts unresolved. True but it is not valid syntax. Like, you mean with the conflict lines?

The conflict lines shown in the article are not present in the file, they are a display of what has already been merged. The merge had changes that were too near each other and so the algorithm determined that someone needs to review it, and the conflict lines are the result of displaying the relevant history due to that determination. In the example in the article, the inserted line from the right change is floating…

Isnt that a bit dangerous in its own? If the merge process can complete without conflicts being resolved, doesnt it just push the Problem down the road? All of a sudden you have to deal with failing CI or ghost features that involve multiple people where actually you just should has solved you conflict locally at merge time.

Re: The future of version control

#287

Post by bawolff »

barrkel wrote: post #96

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

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

I use gerrit extensively... well it does "solve" that problem, i think its far from an ideal solution. It becomes a mess once you have patches depending on other patches and you have to edit a patch somewhere in the stack, and it very much feels bolted on to git. Don't get me wrong, it works, but i think fresh new ideas on how to solve this problem are still needed.

Re: The future of version control

#288

Post by ivlozada »

josephg wrote: post #163
barrkel wrote: post #96

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

CRDTs should be able to give you better merge and rebase behaviour. They essentially make rebase and merge commits the same thing - just different views on a commit, and potentially different ways to present the conflict. CRDTs also behave better when commits get merged multiple times in complex graphs - you don’t run into the problem of commits conflicting with themselves. You should also be able to roll back a sing…

This is the key point. Once your data structure carries the full edit history instead of reconstructing it from DAG traversal, rebase and merge become different views of the same operation. Not fundamentally different operations with different failure modes.

The weave approach moves ordering into the data itself. That's the same insight that matters in any system that needs deterministic ordering across independent participants: put the truth in the structure, not in the topology of how it was assembled.

Re: The future of version control

#289

Post by h14h »

radarsat1 wrote: post #5

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.

Probably depends on what is in the merge. Lately I've been collaborating a ton on PRDs and software specs in markdown (now that agents have gotten pretty good at turning it into usable code) and using git had been pretty painful. Especially when working with a domain expert whose not as technical, git is proving to almost be more of a barrier than an aid.

For this kind of work (which I suspect will only get more common), a CRDT-based VCS makes a lot of sense.

Re: The future of version control

#290

Post by pcthrowaway »

sheept wrote: post #198
mamcx wrote: post #185

Earlier quoted context omitted.

Seriously! Why not show the names of the branch + short Id (and when is not direct name, at least "this is from NAME")

doesn't it? Next to the conflict markers, it'll display HEAD, the ref name, or the short commit hash.

It does now by default, since v2.12 (released 2017). Prior to that you had to set the log.decorate config. Good times.
Post reply on HN