Re:A Coherent Vision for the Future of Version Control
by bigfishrunning on Sunday March 22, 2026 @03:58PM
(#47481468)
Isn't that how the current systems work though? Git inserts conflict markers in the file, and then emacs (or whatever editor) highlights them
The big red block seems the same as "flagged", unless I'm misunderstanding something
Re:A Coherent Vision for the Future of Version Control
by computably on Sunday March 22, 2026 @08:55PM
(#47484151)
With git, conflicts interrupt the merge/rebase. And if you end up in a situation with multiple rebases/merges/both, it's easy to get a "bad" state, or be forced to resolve redundant conflict(s) over and over.
In Jujutsu and Pijul, for example, conflicts are recorded by default but marked as conflict commits/changes. You can continue to make commits/changes on top. Once you resolve the conflict of A+B, no future merges or rebases would cause the same conflict again.
Re:A Coherent Vision for the Future of Version Control
by bigfishrunning on Monday March 23, 2026 @08:41AM
(#47488677)
Thank you for the explanation, i did misunderstand! seems like a neat feature
the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails.