Apologies, but I misunderstood what you meant by the "downstream" conflict situation. That's not possible in git-branchless, but it is possible in Jujutsu, sinc

Apologies, but I misunderstood what you meant by the "downstream" conflict situation. That's not possible in git-branchless, but it is possible in Jujutsu, since it stores conflicts as first-class objects, so it can actually proceed with the application of subsequent patches even if a previous patch conflicted. `git rebase` can be started and aborted, but to start it safely, you have to first set aside all of your existing work in the working copy. You can't really run it on the background or in parallel, which makes it annoying to do operations like rebase all branches, and can ruin build caches, which ends up being a significant problem on larger repositories. It's possible for the UI to show an icon next to each of my branches indicating whether they would rebase onto the main branch successfully, but no interfaces at present do (including my own). Or, for example, I should be able to start dragging a branch to indicate a rebase, and the UI should speculatively check which target branches can be rebased onto successfully and indicate that.