The future of version control • Hacker News Board

Re: The future of version control

#391

Post by adastra22 » Tue, Mar 24, 2026, 2:12 AM UTC

verdverm wrote: post #356

adastra22 wrote: post #281

Earlier quoted context omitted.

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

As a user, why do I care how the internals work? What I do care about is an easy path to progressive adoption and migration. Without that, I cannot convince my team / org to force everyone over.

It solves problems that you dont encounter if you are asking that question. I’ve lost a literal year or more of my life, in aggregate, to rebasing changes against upstream that could have been handled automatically by a sufficiently smart VCS.

Re: The future of version control

#392

Post by Nursie » Tue, Mar 24, 2026, 4:01 AM UTC

philwelch wrote: post #363

Nursie wrote: post #279

Earlier quoted context omitted.

There are those of us who remember the before-times, who I think are in general just happy we have git. Having lived through sccs, pvcs, SourceSafe, Clearcase and svn (among others), the introduction of lightweight, sane branching, merging, rebasing etc was a revelation. Yes, there are still things that an adept could do with some of those other systems that git doesn't make easy. For example we have the holy war bet…

I can definitely relate to that, and I'm actually quite fond of git myself. I just never expected that people would stop trying to make a better version control system. That's not entirely fair, a lot of work has been invested in Pijul and Fossil, but I would have expected much more interest in alternatives. I remember all of the reasons Git was so new and exciting at the time, but now it feels like we're all locked…

It's definitely ruined one of my favourite interview questions. I used to ask candidates what their preferred source control system was and why.

I wanted them to demonstrate that they'd thought about it and had some insight rather than give a specific answer. But now it's just "... uh, git, I've only really used git", and you can't blame anyone for that because it's so dominant now. I've updated my question to be about branching strategies but I'm just not as fond of it.

Well, you've inspired me to have a look more into the competition. I don't think git is perfect, I think it's just good enough and it'll take quite a lot to shift people over to something else now we have the whole github network effect. But hey, no harm in looking around :)

Re: The future of version control

#393

Post by ulrikrasmussen » Tue, Mar 24, 2026, 9:27 AM UTC

sebmellen wrote: post #208

sheept wrote: post #202

Earlier quoted context omitted.

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

"Clean" is not the same as "useful". You have to be really, really disciplined to not make a superficially looking "clean" history which may appear linear but which is actually total nonsense.

For example, if one is frequently doing "fix after rebase" commits, then they are doing it wrong and are making a history which is much less useful than a seemingly more complicated merge based history. Rebased histories are only clean if they also tell a true story after the rebase, but if you push "rebase fixes" onto the end of your history, then it means that prior rebased commits no longer make any sense because they e.g. use APIs that aren't actually there. Giving up and squashing everything to one commit is almost better in this case because it at least won't throw off someone who is trying to make sense of the history in the future.

I think that rebasing has won over merges mostly because the tools for navigating git histories suck SO HARD. I have used Perforce at a previous job, and their graphical tools for navigating a merge based history are excellent and were really useful for doing code archeology.

Re: The future of version control

#394

Post by febusravenga » Tue, Mar 24, 2026, 10:18 AM UTC

tbrownaw wrote: post #178

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…

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

Och, hello fellow monotone user.

Re: The future of version control

#395

Post by jayd16 » Tue, Mar 24, 2026, 3:34 PM UTC

samuelstros wrote: post #390

jayd16 wrote: post #388

Earlier quoted context omitted.

That doesn't really address the game dev use case then. Artists and designers want to prevent conflicts, not just throw away half the work and redo it.

track the source of the asset and it works. take ui design. dont track the svg. track the design file itself

Ok well what if I draw the foreground and you add something to the background and now my changes visually block your changes? Even if the file is merged, our work is wasted and must be redone. P4 is often popular in industry because artists can lock files and inform others that work is being done in that area.

If you actually want to capture those customers it's a use case that needs to be addressed.

Re: The future of version control

#396

Post by gcr » Tue, Mar 24, 2026, 4:49 PM UTC

Here's how jj handles this situation.

I made `foo.py` in ymywkkys, the base change. I added the logging line in ystzrmlq. For the other branch, I ran `jj edit ym` and changed the function body to just `return 42` in vxuxqtnu. Finally, I generate the merge commit with `jj new ym vx`. The graph looks like this:

    @    qttvouvl gcr@hackerne.ws 2026-03-24 10:02:56 (conflict)
    ├─╮  (empty) Some merge commit
    │ ○  ystzrmlq gcr@hackerne.ws 2026-03-24 10:02:54
    │ │  Add logging line
    ○ │  vxuxqtnu gcr@hackerne.ws 2026-03-24 10:02:54
    ├─╯  Just return 42
    ○  ymywkkys gcr@hackerne.ws 2026-03-24 10:02:49
    │  Base function
    ◆  zzzzzzzz root() 00000000

In jj, merges and rebases always succeed, but they may generate conflicts which are first-class objects in the repository alongside files, changes, directories, and so on. Having a structured way of representing conflicts allows for a more structured vocabulary. For instance, "conflict markers" don't live in the file itself, they're just rendered out to the working copy whenever the working copy gets updated.

I personally find this diff harder to read than the proposed format in the post, but the same information is there:

    def calculate(x):
    >>>>>> conflict 1 of 1 ends

Re: The future of version control

#397

Post by yencabulator » Tue, Mar 24, 2026, 7:23 PM UTC

gcr wrote: post #396

Here's how jj handles this situation. I made `foo.py` in ymywkkys, the base change. I added the logging line in ystzrmlq. For the other branch, I ran `jj edit ym` and changed the function body to just `return 42` in vxuxqtnu. Finally, I generate the merge commit with `jj new ym vx`. The graph looks like this: @ qttvouvl gcr@hackerne.ws 2026-03-24 10:02:56 (conflict) ├─╮ (empty) Some merge commit │ ○ ystzrmlq gcr@hack…

Re: The future of version control

#398

Post by yencabulator » Tue, Mar 24, 2026, 7:36 PM UTC

aduwah wrote: post #104

alunchbox wrote: post #36

Jujutsu honestly is the future IMO, it already does what you have outlined but solved in a different way with merges, it'll let you merge but outline you have conflicts that need to be resolved for instance. It's been amazing watching it grow over the last few years.

The only reason I have not defaulted to jj already is the inability to be messy with it. Easy to make mistakes without "git add"

https://docs.jj-vcs.dev/latest/config/#paths-to-automaticall...

Or treat the head commit as just a scratch space and the one before it as equivalent to git staged index, and use `jj squash PATH`, `jj squash -i` etc to "stage" things, or directly `jj commit -m "foo" PATHS` (or -i) to make a new commit with just wanted changed. This is what I do.

Re: The future of version control

#399

Post by verdverm » Tue, Mar 24, 2026, 10:15 PM UTC

adastra22 wrote: post #391

verdverm wrote: post #356

Earlier quoted context omitted.

As a user, why do I care how the internals work? What I do care about is an easy path to progressive adoption and migration. Without that, I cannot convince my team / org to force everyone over.

It solves problems that you dont encounter if you are asking that question. I’ve lost a literal year or more of my life, in aggregate, to rebasing changes against upstream that could have been handled automatically by a sufficiently smart VCS.

An alternative explanation is that I already have a tool that helps me with these situations. The question was a bit rhetorical, because the vast majority of devs don't care what language many of their tools are written in or what algos are used.

A different example, Go's MVS algo can be considered much better for dependency management. What are your thoughts on the SAT solver being replaced in your preferred language tooling? It would mean the end of lock files

Re: The future of version control

#400

Post by brunellus » Tue, Mar 24, 2026, 11:20 PM UTC

roryokane wrote: post #66

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.

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…

roryokane thanks for this example. I tend to stick with git CLI and this was new to me.