That sort of workflow is ideal for making sure you've got a set of isolated commits each looking at a single subject so that when someone is reading through the history later they can quickly see where something was introduced or why, and jj is perfect for doing that because it makes crafting those commits so much easier.
It's very frustrating that what IMO is the inferior approach was producing better results in those teams!
When you are told to separate general code improvements to another PR, or worse, to not do them, and create a Jira task for them so they can be adequately prioritized, it just saps your will to do so. You just won't do any improvements that fall outside the scope of the feature, because even just thinking about the hoops you have to jump through to get work done is mentally draining.
Coincidentally jj makes this process much easier than it would be with git, it will very happily let you shift commits around between different branches, edit commits in place and cleanly rebase those edits onto subsequent commits, or split a messy commit into two commits that makes sense.
If people instead reviewed commit by commit until the PR HEAD, the code itself would tell a story, but best of all - the story would then be obvious!
I can see that.
From the other side of the PR though, it involves significantly _more_ work from a reviewer.
The "red tape" of separating commits and opening separate PRs should be removed by the team.
The effort of separating commits and opening separate PRs is minimal once you're comfortable with the tools.
I encourage colleagues to be comfortable with these workflows, because a reviewer's time is generally no less valuable than their's.
jujutsu also seems like a poor fit for large monorepos repos (particularly ones that use git hooks). The expense of certain git operations increases quadratically with the size of the repo. A repo doesn't need to be terribly large for `git status` to require 5-6 seconds. (God bless the man who added scalar and sparse checkout to git.)
The absolute last thing I want is a tool that's doing more with git -- creating commits, branches, checking things out, rebasing, or doing anything that requires a git-status check.
The best way of getting changes is through is simply sitting down and talking with the reviewer. Most of these small PRS, splitting things, creating elaborate stacking systems are just technology hacks around a social/process problem. I've seen people make more of a mess trying to split pr's up where they are so fine grained its silly and actually had dependencies on commits they didn't realise they had which reviewers then had to resolve. Literally anything to avoid talking and working with people. People are trying to turn a tightly collaborative process and turn it into isolated single work units with no collaboration that just need a rubber stamp.
As opposed to one 33-change PR? Yes, absolutely yes they do.
I probably don’t have time to review a giant PR like that. If I do, I feel guilty asking for fixed in one part when 31 of the changes are great. Why are we holding up all these improvements for one or two small concerns? We can merge and just fix those later. Except that never happens.
I probably have time to review eight one-liners. My other coworker has time for five. After lunch I can quickly check out another seven. Over the course of the day all 33 get reviewed and merged as time allows.
100% this.
With remote teams spread across time zones, mega-PRs become even more problematic.
One commit for a single line? I can't imagine developing software this way. Fixing bugs? Sure. Altering this or that in a well-established, mature codebase? Probably. For features, I don't see how it's possible.
note this is also true in software engineering.
Where the developers at that other company could “take out the trash” amidst one PR, jj makes it trivial to carve off each of those fixes into their own separate PR. It’s no more work than making them separate commits.
People don’t do this in git because it’s a hassle. So you either get cleanup that never comes because each branch needs to know in advance what work it’s going to do or you get omnibus PRs that do twenty different things.
There’s a better way, and it lets you have clean history and developers can fix things they run into along the way.
This is the one thing I always point to when I say "Mercurial is better" (and now, jj).
Why can't we have our cake and eat it? Mercurial lets you have lots of individual commits, but they're hidden, and you'll see only the squashed commit. Why do we have to lose all those individual commits to get that squashed commit? The answer: You don't need to.
Hmm what's the issue with the GitHub default of merging PRs, where there's a merge commit which individually pulls in the PR's commits? You can revert the merge PR as a whole, or the PR commits individually. E.g. with this[1] merge commit, you can `git revert 0a98f570 -m 1` (the merge commit) or `git revert b30950fc` (an individual commit from the PR).
[1] https://github.com/amelioro/ameliorate/commit/0a98f570f63ffd...
A very, very large problem at five out of six companies I have worked at is casual code improvement and refactoring. Devs would say, "we will address that minor and unrelated thing in a separate PR" - one that never comes. At one company, a single PR could address unrelated fixes and it was encouraged to "take out the trash" on the code. Unrelated metrics added, logging improvement, or code simplified, or test robustness improved, etc. That company had vastly better code. Easier to read. Easier to maintain. Easier to observe. And easier to test.