To be clear, I haven’t used jj so please correct any misundersrandings. I hear you and agree that smaller PRs are definitely easier to understand. On the flip side, it sounds like jj just trades large PRs for lots and lots of smaller, independent PRs that are seemingly unrelated despite all belonging to the same change? I wouldn’t see that as better because, on face, it would sound like far more opportunity for changes to leak out of an actual change-set. Or is the suggestion that the advantage is that each one of those discrete changes carries a comment? Because if developers are lazy, which clearly it is laziness to not use stash for unrelated changes, why wouldn’t I expect every comment to eventually be “{feature}” for everything? So now we need to put more policies in place about how devs should spend more time commenting every one-line code change they make that became an individual PR? And I’m sure jj is going to provide me with a handy feature for then re-grouping all these changes together…back into the original big PR that would have existed in the first place? That seems like a circuitous route to arrive at the same place, but with added risk of unintentional, or worse, missing integration of parts of features that appeared to be independent changes? Ive never found it difficult when I make an unrelated change to just stash that change and add it to its own branch related to a bug ticket at the end of my day. Jj wouldn’t replace 90% of those processes so it sounds like a new way to avoid typing a few commands, by typing more commands more frequently and shifting the workload from a single large relevant change to many, many small changes, all of which were still part of the same set of changes.

None of that sounds like a positive to me, so I’d rather appreciate some evangelism to enlighten me and correct my misjudgments/misunderstandings which I fully admit are likely. :-)