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

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 +++++++ vxuxqtnu "Just return 42" return 42 %%%%%%% diff from: ymywkkys "Base function" \\\\\\\ to: qttvouvl "Some merge commit" (rebased revision) a = x * 2 + logger.debug(f"a={a}") b = a + 1 return b >>>>>>> conflict 1 of 1 ends