The most common thing that causes me pain in git today is asynchronous review of a chain of commits. If you work in a commit to trunk model, every commit needs

The most common thing that causes me pain in git today is asynchronous review of a chain of commits. If you work in a commit to trunk model, every commit needs to build and pass tests and be a self-contained unit of work, ideally small, so it's quick to review. Since you don't want to be held up by the speed of review, you make more commits, each one building on the last, to form a chain. The chain of commits is reviewed, each commit separately, and they're merged in order as you go, in one big bunch at the end, or some mix. That doesn't really matter. The problem is addressing review comments on early commits in a chain. With git, you need to stash your work or make a WIP commit, jump to the right commit, made edits, then rebase the rest of your chain on that commit. This requires fiddly copying of commit hashes or a proliferation of branch names. If you have a tree of commits instead of a linear chain, it's even more work. Ideally, when looking at all the comments on your chain of commits, you just make local edits and run a magic command which amends every commit each edit "belongs" to, automatically - this is what `hg absorb` does in mercurial. (All of the above shouldn't be mistaken for saying jj makes this easier to do. I don't know if it does. I just know that git is painful for this workflow and I'd like something better.)