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

201–210 of 407 posts

Re: The future of version control

#201

Post by josephg »

sroussey wrote: post #180
josephg wrote: post #163

Earlier quoted context omitted.

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…

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

The second meaning is "conflict" as in "git commit conflict", where a merge gets marked as requiring human intervention.

Once you define the terms correctly, its possible to write a CRDT-with-commit-conflicts. Just define a "conflict marker" which are sometimes emitted when merging. Then merging can be defined to always succeed, sometimes emitting conflict markers along the way.

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

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.

Re: The future of version control

#202

Post by sheept »

marcellus23 wrote: post #109
IgorPartola wrote: post #97

Earlier quoted context omitted.

Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense. What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?

"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into).

Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better without rebases and squash commits.

Re: The future of version control

#203

Post by hn_throwaway_99 »

cxr wrote: post #110
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.

> I don't understand why you need to switch out the VCS to fix that issue. For some reason, when it comes to this subject, most people don't think about the problem as much as they think they've thought about it. I recently listened to an episode on a well-liked and respected podcast featuring a guest there to talk about version control systems—including their own new one they were there to promote—and what factors m…

> they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over.

It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why. I understand how commit snapshots and packfiles work, and the way delta compression works in packfiles might lead me to calling it "storing diffs" in a colloquial setting.

Re: The future of version control

#204

Post by ramchip »

stbtrax wrote: post #200
roryokane wrote: post #60

Earlier quoted context omitted.

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

how do you set that up? the default git tool version seems to be 3 pane

Looks like it's "Show Base" under the top-level "..." menu when working on a merge conflict

https://github.com/microsoft/vscode/issues/155277#issuecomme...

Re: The future of version control

#205

Post by philwelch »

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.

Re: The future of version control

#206

Post by cerved »

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

Re: The future of version control

#207

Post by cerved »

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.

Tip, you may want to use origin/HEAD over origin/master

Re: The future of version control

#208

Post by sebmellen »

sheept wrote: post #202
marcellus23 wrote: post #109

Earlier quoted context omitted.

That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense. What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?

"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better wit…

Wow, interesting to see such a diametrically opposed view. We’ve banned merge commits internally and our entire workflow is rebase driven. Generally, I find that rebases are far better at keeping Git history clean and clearly allowing you to see the diff between the base you’re merging into and the changes you’ve made.

Re: The future of version control

#209

Post by KPGv2 »

I've tested out jj a bit, and doesn't it solve the issues presented at the link already? I don't work on a team where I need VC better than git, so I just stick with it for my own private use, but I did test jj out of curiosity, and I could've sworn this is basically the same pitch as switching to jj (but for the CRDT under the hood).

Re: The future of version control

#210

Post by wakawaka28 »

psychoslave wrote: post #76
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…

That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabul…

>Maybe "local/alien" might be a less pompous vocabulary to convey the same idea.

That is more alien and just as contrived. If you merge branches that you made, they're both local and "ours". You just have to remember that "ours" is the branch you are on, and "theirs" is the other one. I have no idea what happens in an octopus merge but anyway, the option exists to show commit titles along with markers to help you keep it straight.

Post reply on HN