3 ms·
They address this; it's not that they don't fail, in practice... the key insight is that changes should be flagged as conflicting when they touch each other, g
by hungryhobbit 7mo ago
They address this; it's not that they don't fail, in practice...
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.
- bigfishrunning 7mo agoIsn'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
- computably 7mo agoWith 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.
- bigfishrunning 7mo agoThank you for the explanation, i did misunderstand! seems like a neat feature