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

51–60 of 407 posts

Re: The future of version control

#51

Post by conradludgate »

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.

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

Re: The future of version control

#52

Post by [deleted] »

skybrian wrote: post #32

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…

[deleted]

Re: The future of version control

#53

Post by zahlman »

simonw wrote: post #9

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.

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.

Re: The future of version control

#54

Post by jedberg »

codethief wrote: post #17
simonw wrote: post #11

Earlier quoted context omitted.

I hadn't heard of Pijul. My first search took me to 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 had a commit last month. ... and of course it is, because Pijul uses Pijul for development, not Git and GitHub!

> I hadn't heard of Pijul 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.

I too am here all the time and have never heard of it. But it looks interesting.

Re: The future of version control

#55

Post by skydhash »

jwilliams wrote: post #44
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.

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.

I'm surprised to see that some people sync their working tree and does not evaluate their patch again (testing and reviewing the assumptions they have made for their changes).

Re: The future of version control

#56

Post by dboreham »

bos wrote: post #2

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

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

Re: The future of version control

#57

Post by nozzlegear »

jFriedensreich wrote: post #16

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…

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

Re: The future of version control

#58

Post by ozten »

idoubtit wrote: post #15
simonw wrote: post #11

Earlier quoted context omitted.

I hadn't heard of Pijul. My first search took me to 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 had a commit last month. ... and of course it is, because Pijul uses Pijul for development, not Git and GitHub!

The canonical website is https://pijul.org . The homepage has a link to the pijul source repository.

They should mirror on GitHub for marketing purposes

Re: The future of version control

#59

Post by rightbyte »

conradludgate wrote: post #51
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.

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

> You can commit with conflicts unresolved.

True but it is not valid syntax. Like, you mean with the conflict lines?

Re: The future of version control

#60

Post by roryokane »

crote wrote: post #24
ulrikrasmussen wrote: post #19

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.

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.

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.

Post reply on HN