The future of version control

Posted by c17r 8 hours ago

The future of version control(bramcohen.com)

330 points | 181 commentspage 4

alunchbox 6 hours ago|

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.

aduwah 5 hours ago|

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"

llyama 4 hours ago|||

You can be messy. The lack of an explicit staging area doesn't restrict that. `jj commit` gives the same mental model for "I want to commit 2 files from the 5 I've changed".

dzaima 4 hours ago|||

But you do have the op log, giving you a full copy of the log (incl. the contents of the workspace) at every operation, so you can get out of such mistakes with some finagling.

You can choose to have a workflow where you're never directly editing any commit to "gain back autonomy" of the working copy; and if you really want to, with some scripting, you can even emulate a staging area with a specially-formatted commit below the working copy commit.

phtrivier 6 hours ago||

A suggestion : is there any info to provide in diffs that is faster to parse than "left" and "right" ? Can the system have enough data to print "bob@foo.bar changed this" ?

lasgawe 6 hours ago||

This is a really interesting and well thought out idea, especially the way it turns conflicts into something informative instead of blocking. The improved conflict display alone makes it much easier to understand what actually happened. I think using CRDTs to guarantee merges always succeed while still keeping useful history feels like a strong direction for version control. Looks like a solid concept!

ballsweat 4 hours ago||

Cool timing.

I recently built Artifact: https://www.paganartifact.com/benny/artifact

Mirror: https://github.com/bennyschmidt/artifact

In case anyone was curious what a full rewrite of git would look like in Node!

The main difference is that on the server I only store deltas, not files, and the repo is “built”.

But yeah full alternative to git with familiar commands, and a hub to go with it.

skybrian 6 hours ago||

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 before sending a pull request.

dcre 4 hours ago||

This is a reasonable reaction — pretty sure I felt the same way when I heard about jujutsu's first-class conflicts[0] — but it turns out to be really useful not to be stuck inside an aberrant state while conflicts are in the process of being resolved.

[0]: https://docs.jj-vcs.dev/latest/conflicts/

dzaima 1 hour ago|||

In git if you, say, do some `git rebase -i`, edit some commit, continue the rebase, and hit a conflict, and realize you edited something wrong that caused the conflict, your only option is aborting the entire rebase and starting over and rebuilding all changes you did.

In jj, you just have a descending conflict, and if you edit the past to no longer conflict the conflict disappears; kinda as if you were always in interactive rebase but at all points have the knowledge of what future would look like if you `git rebase --continue`d.

Also really nice for reordering commits which can result in conflicts, but leaves descendants non-conflicting, allowing delaying resolving the conflicts after doing other stuff, or continuing doing some reordering instead of always starting from scratch as with `git rebase -i`.

echrisinger 4 hours ago||

Has anyone considered a VCS that integrates more vertically with the source code through ASTs?

IE if I change something in my data model, that change & context could be surfaced with agentic tooling.

sibeliuss 5 hours ago||

Why must everyone preprocess their blog posts with ChatGPT? It is such a disservice to ones ideas.

jauntywundrkind 7 hours ago||

In case the name doesn't jump out at you, this is Bram Cohen, inventory of Bittorrent. And Chia proof-of-storage (probably better descriptions available) cryptocurrency. https://en.wikipedia.org/wiki/Bram_Cohen

It's not the same as capturing it, but I would also note that there are a wide wide variety of ways to get 3-way merges / 3 way diffs from git too. One semi-recent submission (2022 discussing a 2017) discussed diff3 and has some excellent comments (https://news.ycombinator.com/item?id=31075608), including a fantastic incredibly wide ranging round up of merge tools (https://www.eseth.org/2020/mergetools.html).

However/alas git 2.35's (2022) fabulous zdiff3 doesn't seems to have any big discussions. Other links welcome but perhaps https://neg4n.dev/blog/understanding-zealous-diff3-style-git...? It works excellently for me; enthusiastically recommended!

braidedpubes 4 hours ago|

Do I have it right that it’s basically timestamp based, except not based on our clocks but one it manages itself?

So as long as all updates have been sent to the server from all clients, it will know what “time” each character changed and be able to merge automatically.

Is that it basically?

More comments...