You’re still treating code as text which it isn’t (in the same way you wouldn’t treat JSON as text) it’s actually more like an AST.
Jujutsi (jj) does that. And it’s git compatible.
The future of version control
191–200 of 407 posts
Re: The future of version control
#192I'm surprised to see the emphasis on tracking lines of text, which ties in to the complexity of merge vs merge-the-other-way vs rebase. If we are committed to enhancing the change history, it seems wiser to go all in and store high-level, semantically-meaningful changes, like "move this code into an `if` block and add `else` block ...".
Consider the first example in the readme, "Left deletes the entire function [calculate]. Right adds a logging line in the middle". If you store the left operation as "delete function calculate" and the right operation as "add line ... to function calculate", then it's obvious how to get the intended result (calculate is completely deleted), regardless of how you order these operations.
I personally think of version control's job not as collaborating on the actual files, but as collaborating on the canonical order of (high-level) operations on those files. This is what a branch is; merge/rebase/cherry-pick are ways of updating a branch's operation order, and you fix a conflict by adding new operations on top. (Though I argue rebase makes the most sense in this model: your end goal is to append to the main branch.)
Once you have high-level operations, you can start adding high-level conflict markers like "this operation changed the docs for function foo; flag a conflict on any new calls to foo". Note that you will need to remember some info about operations' original context (not just their eventual order in the main branch) to surface these conflicts.
Re: The future of version control
#193You’re still treating code as text which it isn’t (in the same way you wouldn’t treat JSON as text) it’s actually more like an AST. Jujutsi (jj) does that. And it’s git compatible.
I love jj and think virtually every git user should switch to it, but I don't think it treats text as an AST. What do you mean?
Re: The future of version control
#194It 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…
[deleted]
Re: The future of version control
#195It 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…
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`.
Re: The future of version control
#196This is sort of a revival and elaboration of some of Bram’s ideas from Codeville, an earlier effort that dates back to the early 2000s Cambrian explosion of DVCS. Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper). Codeville predates the introduction of CRDTs by almost a decade, and at least on the face of it the two concepts seem like a nat…
The whole point of using a proper CRDT is that it's easy to reason about what it does. It took me a while to figure out the details of how to build one.
Re: The future of version control
#197starts 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…
The rest of the article shows exactly how a CRDT is a sound base for a version control system, with "conflicts" and all.
where?
Re: The future of version control
#198Earlier quoted context omitted.
After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly
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.
Re: The future of version control
#199Earlier quoted context omitted.
They should mirror on GitHub for marketing purposes
How would they do that if they don't use git for version control? Does GitHub allow other forms of version control other than git?
SQLite does it despite using Fossil - their mirror is at https://github.com/sqlite/sqlite
Git is so established now that it's sensible for alternative VCS to have a mode where they can imitate the Git protocol - or seven without that you can still checkout the latest version of your repo and git push that on a periodic basis.
Re: The future of version control
#200Earlier quoted context omitted.
Seconding the use of p4merge for easy-to-use three-pane merging. Just like most other issues with Git, if your merges are painful it's probably due to terrible native UX design - not due to anything conceptually wrong with Git.
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