[normie3000]

> It's because what you see as the inferior approach involves less effort and friction for the developers.

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.

[UK-Al05]

Reviewers don't want to navigate 33 tiny PRS either.

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.

[stouset]

> Reviewers don't want to navigate 33 tiny PRS either.

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.

[normie3000]

> As opposed to one 33-change PR? Yes, absolutely yes they do.

100% this.

With remote teams spread across time zones, mega-PRs become even more problematic.

[globnomulous]

> one-liners

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.

[nchmy]

Jj makes this effort vastly easier. Nearly frictionless.

[normie3000]

Great. As I said elsewhere on this story, I'll suggest jj to colleagues who struggle with git.

[globnomulous]

Yeah, I don't get it. Maybe I'm just confused but the git mental model has never struck me as complex or confusing.

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.