Sorry, but as another commenter said, you may not like Pijul for whatever reason or think it's "bad" someone is working on it, but your argument that git's mode

Sorry, but as another commenter said, you may not like Pijul for whatever reason or think it's "bad" someone is working on it, but your argument that git's model is not exposed to the user and that there is no difference is simply not true. I recently had issues with Git's model of merging come up and it broke a very important build in our Linux distribution (OpenJDK), due to an erroneous merge that Git applied without warning or conflict: https://github.com/NixOS/nixpkgs/commit/5d0ef3fd900769e82175078b76261e1c952f776f#commitcomment-31341890 https://github.com/NixOS/nixpkgs/commit/5d0ef3fd900769e82175... To repeat the issue: I basically broke a build on our Linux distribution when I cherry picked a change after what git thought was a file rename -- it was not actually a file rename. An entire new file that was mostly similar was added, effectively resulting in Git thinking it was a move. - `10.nix` for JDK 10 was removed, and JDK 11 (via `11.nix`) was added in 1bd7b98c7975136ddd6183a155e90688fd5b3e43, all in the same commit - JDK 11 was only added in `master`, not in `release-18.09` - Because these files were substantially the same, `git` tracked this 10 -> 11 upgrade (from `10.nix` to `11.nix`) heuristically as a file rename. - I committed 162914742327002d49bd1dde424d399842ff7b5f on `master` as a change to OpenJDK 11 - I cherry-picked that to `release-18.09`, in this commit - Git saw that the change was applied to `11.nix`, but that change was not applied on this branch, so that file did not exist. - But git *thinks* that `11.nix` came directly from `10.nix`, through a file rename, i.e. the files are "the same" in some sense (even though they substantially differ in functionality, now) - Therefore, `git` concludes it's safe and appropriate to "rebase" this cherry-pick on top of `10.nix` - And then the build fails, because ZGC is not available in OpenJDK 10 ----- I used Darcs for years before moving to Git, and this would have never happened with either Darcs or Pijul -- and not just because they actually track renames more accurately, more complicated merge issues that can arise from Git's model are also handled elegantly and correctly. The tool would have instead warned me that any cherry pick would have required a dependent patch (the one that added OpenJDK 11) that wasn't already there, and I would have been immediately informed of it -- a case that Git completely failed at. That's the wrong behavior, no matter what way you cut it. (Of course, I use Git every day despite this, and it works about 90% of the time.) Many other very useful workflows are made easier by the fact that in the model of Darcs and Pijul, patches are treated as commutative, and that fact is tracked correctly -- doing things like cherry-picks to stable branches (something I did for years as part of a large project -- one that use Darcs first and moved to Git!) becomes far easier because it's always clear when dependent changes are needed and how they interact, and when you want to pull them vs author bespoke patches for different branches, etc.