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

231–240 of 407 posts

Re: The future of version control

#231

Post by lmm »

KPGv2 wrote: post #211
sheept wrote: post #198

Earlier quoted context omitted.

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

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.

Re: The future of version control

#232

Post by Androider »

I've had really good success lately with having Claude Code resolve conflicts, to the point that I don't see myself doing manual resolutions going forward.

Set git.conflictStyle to zdiff3 and ask Claude to resolve the conflict, or even better, complete the entire rebase for you. A quick diff sanity check against the merge base of the result takes just a few seconds.

Re: The future of version control

#233

Post by mememememememo »

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…

But merging already auto-merges what it can best effort. Conflicts are syntax conflicts not semantic ones.

Therefore you could have automerges that conflict in a way that breaks the code.

Example would be define a global constant in file X. One commit removes it. Another commit on another branch makes use of it in file Y.

OTOH where I get merge conflicts in Git it is usually purely syntax issue that could be solved by a slightly cleverer merge algo. CRDT or semantic merge.

Re: The future of version control

#234

Post by mememememememo »

Retr0id wrote: post #188
tbrownaw wrote: post #178

Earlier quoted context omitted.

> You can't use CRDTs for version control You misunderstand what is being proposed. Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy. . Consider for example if you want to track and merge scalar values. Maybe file names if you track rena…

If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?

Syntax-only manual merges are just time consuming waste of human time.

I'm a small PR-er so 99% of the time it is Syntax. If if it is semnatic at all often then try trunk based development.

Re: The future of version control

#235

Post by pfg_ »

IshKebab wrote: post #123
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…

This is better but it still doesn't really help when the conflict is 1000 lines and one side changed one character and the other deleted the whole thing. That isn't theoretical - it happens quite regularly. What you really need is the ability to diff the base and "ours" or "theirs". I've found most different UIs can't do this. VSCode can, but it's difficult to get to. I haven't tried p4merge though - if it can do tha…

I tried p4merge a while ago and it didn't do it ubfortunately, still stuck copying the base and ours to seperate files and diffing them.

Re: The future of version control

#236

Post by Retr0id »

mememememememo wrote: post #234
Retr0id wrote: post #188

Earlier quoted context omitted.

If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?

Syntax-only manual merges are just time consuming waste of human time. I'm a small PR-er so 99% of the time it is Syntax. If if it is semnatic at all often then try trunk based development.

The CRDT isn't syntax-aware either

Re: The future of version control

#237

Post by mememememememo »

Androider wrote: post #232

I've had really good success lately with having Claude Code resolve conflicts, to the point that I don't see myself doing manual resolutions going forward. Set git.conflictStyle to zdiff3 and ask Claude to resolve the conflict, or even better, complete the entire rebase for you. A quick diff sanity check against the merge base of the result takes just a few seconds.

Thanks literally just used this!

Re: The future of version control

#238

Post by mikey-k »

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

Interesting idea. While conflicts can be improved, I personally don't see it as a critical challenge with VCS. What I do think is the critical challenge (particularly with Git) is scalability. 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. What exactly, I don't know. :). But I do know that in my curre…

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 can probably go figure out enough context to "figure things out".

Re: The future of version control

#239

Post by mememememememo »

Retr0id wrote: post #236
mememememememo wrote: post #234

Earlier quoted context omitted.

Syntax-only manual merges are just time consuming waste of human time. I'm a small PR-er so 99% of the time it is Syntax. If if it is semnatic at all often then try trunk based development.

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.

Re: The future of version control

#240

Post by gwerbin »

KPGv2 wrote: post #211
sheept wrote: post #198

Earlier quoted context omitted.

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

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 learned that rule and took the time to internalize it, I at least never got confused on this particular detail again.

> fake history

That's the thing, it's not actually fake history. Git really is doing the things it looks like it's doing during a rebase. That's why you can do all kinds of weird tricks like stopping in the middle to reset back a commit in order to make a new intervening commit. The reason you can abort at any time with (almost) no risk is because the old history is still hanging around in the database and won't be removed until GC runs, usually long after the rebase is settled.

Post reply on HN