| Lemme give you one example of one workflow I've encountered a bunch of times that's super annoying with git. I port/test a project to a new OS. I run into a bunch of issues, like linkers, environments, etc. that are broken that I need to fix. I try and make clean commits tackling one issue at a time, so we get 1 commit for the linker issues, 1 for the docs, 1 for the environment, etc. eventually I have 5 commits of fixes. These fixes are all orthogonal, so ideally I want to make separate PRs and separate reviews for them. But locally they're all tied together (in chronological order), since I need all of them there to continue development. In git I can either open 1 big PR including all fixes at once (annoying) or I can make a PR for one commit, wait until it's merged, then PR the next, etc. The only way to get them nicely separate is if I take all those 5 commits, rebase each of them onto master in its own branch and PR those 5 branches. But that ruins my ability to work locally. The associativity of (non-conflicting) patches in a patch based VCS like Anu/Pijul means that this "ordering" of patches doesn't exist. I have 5 patches you don't, I can PR each of them independently without needing to manipulate history or anything, because fundamentally the patches aren't related and therefore there's no reason for an ordering like the git DAG forces upon you. Of course this is a fairly niche (but hopefully concrete enough) example of how this enforced ordering of commits can actively harm workflows/collaboration. |