Whereas in Pijul and Darcs, commits (called patches) are diffs, not snapshots. They are based on a sound theory of patches, which allows for operations not supported by Git like commuting, as long as the commits aren't interdependent. Plus, language-specific tools can extend the notion of dependency from line-based to semantic.
> They are based on a sound theory of patches, which allows for operations not supported by Git like commuting, as long as the commits aren't interdependent.
This is definitely supported by git. Even though commits may technically be snapshots, you can build a diff from snapshots (and vice versa). `git diff` will get you the diff for any given commit, and `git rebase` will happily reorder commits for you by reapplying the diffs.
When reading a bit about Pijul, a few months back, I had assumed every two patches would commute, and I couldn't image how that could possibly work.
Does it really have this limitation? If so, it doesn't look much of an improvement compared to git: I can shuffle "patches" all right using `git rebase -i`. I conceide it can be quite slow, though.
So not every patch can commute with every other patch: “delete foo” doesn’t make sense until after “add foo” has happened. So patches have dependencies that they must come after, but for lots of vc situations, patches are independent. Sets of patches makes rebasing a branch trivial for example because adding the patches from the master after your patches is equivalent to adding them before. If you would get a merge conflict, you get the same merge conflict whether they are added before or after.
But nailing down the logic behind commuting patches can be important too as it can catch subtle problems that might happen with normal snapshot-based merging. Consider some people independently editing branches
Bob adds a file with line “foo”
Alice pulls Bob’s patch
Bob changes “foo” to “bar”
Alice changes “foo” to “bar”
Bob changes “bar” back to “foo”
In Pijul or Darcs you should get a consistent result pulling changes from Bob and Alice no matter what order you do it. But if you use something like git, the order you pull and merge, and if you do it at any intermediate times, might change the resulting snapshot (as well as just the history). The start and end state of Bob’s repo loom the same as snapshots but they are different because Bob changed his mind about the line “bar”—maybe the change didn’t work.
