Thx oh and maybe don't call it sem. It's not really semantic, more like a big picture view vs the ground level git lines. How about "bye", short for bird's-eye?
Another potential use case:
This may help jujutsu auto split a large revision into small orthogonal revs.
Sometimes agent makes a monolithic commit and it's a lot of work to manually split code you didn't write. After such an auto split I can manually squash related revs into feature/ticket level.
Biggest design bug imo is the workers need to register for the workflows they support, but will happily pull tasks from unrelated workflows if they're on the same queue. No way to put failed tasks back into the queue again either.
Me too! I got interested in category theory and how to express a logical model of "workflows" as a category. Then ai told me workflows are a monoid and not to bother.
Strange advice not to push the mega merge. It's what I call my release branch.
One thing I like is there's many ways to achieve the same result. E.g. author uses a fancy rebase to graft a new branch between trunk and merge point. I could do the same by: 1) rebase -s onto trunk, 2) merge new branch with mega merge, 3) squash old megamerge upwards into new merge. No cryptic revset needed.