Jujutsu megamerges for fun and profit

Post by e40 » Tue, Apr 21, 2026, 8:48 AM UTC

quicksnap wrote: post #57

Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state. And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged. When I first tried to use jj,…

Post by bilekas » Tue, Apr 21, 2026, 8:54 AM UTC

jychang wrote: post #106

bilekas wrote: post #104

I think I'm missing some major selling point of jj, to me it's just git with a different flow that might be more suitable for a rare few cases where heavy parallel work is happening, and even then git is fine if people know what they're doing, the idea of no staging areas doesn't appeal to me, mutable commits seems actively negative to me personally. I understand if people are enjoying it great, but the amount of pra…

Did you read the article? > Basically, in the megamerge workflow you are rarely working directly off the tips of your branches. Instead, you create an octopus merge commit (hereafter referred to as “the megamerge”) as the child of every working branch you care about. This means bugfixes, feature branches, branches you’re waiting on PRs for, other peoples’ branches you need your code to work with, local environment se…

Post by mi_lk » Tue, Apr 21, 2026, 9:34 AM UTC

SOLAR_FIELDS wrote: post #76

surajrmal wrote: post #75

Earlier quoted context omitted.

If you wrangle a lot of in flight changes that are not yet merged into your teams primary git repo, it's very helpful. I have some 10-30 changes in various states at any time. Sometimes they have dependencies on each other sometimes they don't. Placing them all into one branch can work but it's a lot less ergonomic in many ways. jj makes my life simpler because it accommodates my workflow in a way git doesn't. Honest…

Every time I hear about this megamerge and stacked pr nonsense, it just smells to me. Like, why does your engineering organization have a culture where this sort of nonsense is required in the first place? Anytime I see articles like this gushing about how great tool XYZ is for stack merging and things like that, all I hear is "you don't have a culture where you can get someone looking at and mainlining your PR on th…

Post by maleldil » Tue, Apr 21, 2026, 10:05 AM UTC

dbt00 wrote: post #63

ksymph wrote: post #43

Semi off-topic, but does anyone know of good resources for jj that don't assume git knowledge? Steve's and others are high quality, but often things are explained in terms of git equivalents or describe workflows that I struggle to fully understand the purpose of, as someone who knows only the barest basics of git necessary to work on personal projects. If none exist, I think there's a great opportunity there, for an…

Honestly, until JJ is 1.0, I wouldn't recommend it for beginners. There's significant changes happening to the interface still.

Post by codethief » Tue, Apr 21, 2026, 10:22 AM UTC

jFriedensreich wrote: post #109

bilekas wrote: post #104

I think I'm missing some major selling point of jj, to me it's just git with a different flow that might be more suitable for a rare few cases where heavy parallel work is happening, and even then git is fine if people know what they're doing, the idea of no staging areas doesn't appeal to me, mutable commits seems actively negative to me personally. I understand if people are enjoying it great, but the amount of pra…

You have to look at it from the workflow side not compare the tool on your current git workflow. Check out https://www.stacking.dev for a description of stacked commits, which is more the everyday workflow on jj than the octopus in this article.