It is actually defined as "you get the same file contents and directory structure, regardless of the order in which you apply the changes", which is quite good.

It is actually defined as "you get the same file contents and directory structure, regardless of the order in which you apply the changes", which is quite good. > But, this seems to require semantic level understanding of the code No: you may very well have two different orders yielding the same output, even though the output is incorrect. > This method seems to rely inherently on the fact that git commits are ordered. How would this work with a pijul-based flow? Good question. Our CI over at https://nest.pijul.com/pijul/pijul/ci https://nest.pijul.com/pijul/pijul/ci works in the same way. Patches are ordered in Pijul too, but the order is local. In your example, if Alice wins, Bob will pull her patch, fix his code, which will produce another patch. He will then send it to CI again (or directly to main if he's careless), and Alice will pull both Bob's original patch and the fix. In the end, they will have different histories, but the exact same contents.