I have clarified the comment above. A pull is needed before pushing. That pull does not need a merge or a rebase like git does because the order of commits A nd B does not matter (iff they are commutative). This gets a lot more useful when there are more than two patches to consider.

That seems like a very important point; how does pijul deal with such "effects at a distance"?

By not being a CI tool, nor claiming to solve such Turing-complete problems.

Pijul has a theory of textual changes, but indeed doesn't care at all about what you write in your files: that's your problem!

> Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact.

A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines.

And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.