Pijul can detect when a patch commutes and when it does not. From there it can construct a dependency graph of commits and use that information in various interesting and useful ways. Back when I used Darcs I would somewhat frequently do things like pull these three commits and their decscendants as a sort of pseudo branch that would include everything necessary for a specific line of work but leave everything else behind.

To the point of the article when commits are diffs you sort of intuitively think such things should be possible. But because in git commits are snapshots it's not as easy as you would expect it to be.

Yes, patches aren't commutative in general. That is precisely the reason Pijul can help us in these situations, and guarantee the result will be the same: it will either work without issue, or it will abort due to non-commutative patches (it's similar to a type checker, which either guarantees that functions won't be called with the wrong type of argument, or aborts because the types don't match up)

From my understanding, the 'history/ordering mechanism' in Pijul is composition of patches. In general, the patch 'patch1 ∘ patch2' can be different from the patch 'patch2 ∘ patch1'; when they just-so-happen to be the same, we say that patch1 and patch2 commute.

> In general, the patch 'patch1 ∘ patch2' can be different from the patch 'patch2 ∘ patch1'.

That isn't true. In Pijul, either patch1 explicitly depends on patch2, or patch2 explicitly depends on patch1, or else these two things you said are equal.