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

261–270 of 407 posts

Re: The future of version control

#261

Post by jFriedensreich »

nozzlegear wrote: post #57
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.

the latest codex or opus 4.6 depending what works better. the trick is not to work on giant rebases at all. use commit stacks that constantly rebase on trunk so will constantly have small conflicts that are simple to resolve rather than waiting for giant headaches. another one is to use jj and resolve conflicts "through the stack" so you rebase your work stack, then resolve conflicts from the bottom commit up, one by one, not all at once.

Re: The future of version control

#262

Post by onoesworkacct »

vova_hn2 wrote: post #63
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.

I have a weird hobby: about once a year I go to the theory page [0] in pijul manual and see if they have fixed the TeX formatting yet. You would think that if a better, more sound model of storing patches is your whole selling point , you would want to make as easy as possible for people who are interested in the project to actually understand it. It is really weird not to care about the first impression that your ma…

I mean, I personally just saw some stuff inside dollar signs and went "huh, weird choice of delimiter"

Re: The future of version control

#263

Post by zephen »

Retr0id wrote: post #229
furyofantares wrote: post #228

Earlier quoted context omitted.

> the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently.

Why is that valuable?

Yeah, symmetry is overrated.

Git's merge is already symmetrical for two branches being merged, and that, in and of itself, often leads to problems.

It's completely unclear that extending this to multiple branches would provide any goodness.

Re: The future of version control

#264

Post by drfloyd51 »

Retr0id wrote: post #229
furyofantares wrote: post #228

Earlier quoted context omitted.

> the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently.

Why is that valuable?

It means anyone can fix the conflict. Including a server side AI.

Re: The future of version control

#266

Post by zahlman »

josephg wrote: post #165
zahlman wrote: post #53

Earlier quoted context omitted.

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.

I bet you can make a small, beautiful implementation of this algorithm in most languages. Most algorithms - even ones that take generations of researchers to figure out - end up tiny in practice if you put the work in to understand them properly and program them in a beautiful way. Transformers are the same. Genius idea. But a very small amount of code to implement. This is an implementation of FugueMax (Weidner and…

I'm not familiar with CRDT but the code does look pretty nice. I actually have been thinking myself of streaming my development, but just the terminal without camera or microphone. (So I think I want to wait until I'm doing something that will look pretty in the terminal.)

Re: The future of version control

#267

Post by skydhash »

gwerbin wrote: post #240
KPGv2 wrote: post #211

Earlier quoted context omitted.

I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source proj…

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

Re: The future of version control

#268

Post by jimbobimbo »

lmm wrote: post #231
KPGv2 wrote: post #211

Earlier quoted context omitted.

I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source proj…

I avoid this problem by not rebasing.

Seriously! I have too many years of software development experience, but I use Visual Studio UX to handle pretty much all git operations. And always merge.

I have better things to do in my life than "internalizing" anything that doesn't matter in the grand scheme of things.

Re: The future of version control

#269

Post by skydhash »

orthoxerox wrote: post #160
Sharlin wrote: post #139

Earlier quoted context omitted.

git checkout mybranch git rebase main Now git takes main and starts cloning (cherry-picking, as you said) commits from mybranch on top of it. From git's viewpoint it's working on top of main, so if a conflict occurs, main is "ours" and mybranch is "theirs". But from your viewpoint you're still on mybranch, and indeed are left on mybranch when the rebase is complete. (It's a different mybranch, of course; once the reb…

I had to make an alias for rebasing, because I kept doing the opposite: git checkout master #check out the branch to apply commits to git rebase mybranch #Apply all commits from mybranch Now I just write rebase-current-branch and it does what I want: fetches origin/master and rebases my working branch on top of it. But "ours"/"theirs" still keeps tripping me up.

You can use the --onto flag for git rebase

  git rebase --onto origin/master
It will checkout origin/master and replay the current branch on top.

P.S. I had to check the man page as I use Magit. In the latter I tap r, then u. In magit my upstream is usually the main trunk. You can also tap e instead of u to choose the base branch.

Re: The future of version control

#270

Post by vlovich123 »

mememememememo wrote: post #239
Retr0id wrote: post #236

Earlier quoted context omitted.

The CRDT isn't syntax-aware either

If it is doing what I think CRDT does, and tracking where the user clicked and what they typed, it sort of carries a bit more syntax info. It has a chance to get it right. And often since it does something it turns a figure this shit out with review this.

Much better is AST merging (which itself is also more amenable to crdts). But doing this at the text level is doing to be a failed experiment - the value isn’t there.
Post reply on HN