> why does pijul decide that the correct merge is only adding the X line after the second instance of AB? It doesn't decide, it only guarantees that the order

> why does pijul decide that the correct merge is only adding the X line after the second instance of AB? It doesn't decide, it only guarantees that the order between lines is preserved in all cases. Also, since you seem to have "thought a lot about the problem", you probably noticed that what Git does is totally wrong, since what it does depends on whether you merge both commits at once, or one at a time! > the same person will often want different algebraic operations in different settings. I doubt that when Alice adds line at the top of the file, while Bob edits the bottom of the file, anyone would ever want Bob's new lines merged in the middle of Alice's new lines. Yet, that is what Git does. > it is quite clear from this pijul example that they haven't really thought about the problem much. Or maybe they have, and they have thought enough about it to notice that 3-way merge is doing the wrong thing, and that trying to merge snapshot doesn't even make any sense. They might have also thought enough about Git to understand that rebase is turning commits into patches, one by one, in order to "replay them on top of the current version". While I do agree that full versions are important for storage (and all version control systems, including patch-based ones, are able to recover full versions), they are not very useful to merge work, or to solve conflicts.