[RUnconcerned]

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

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.

[jon-wood]

I don't know how but we need to get developers out of thinking of PRs as the smallest possible change unit. This is literally what commits are for, you do a chunk of work, and you have a commit which describes that chunk of work. If you've got cleanly isolated commits then when you come to reviewing the PR (or changeset as I'd much rather see them called) and someone questions the wisdom of including that particular change you can either modify the commit to satisfy the questions, or just pull it out of the changeset into it's own for later review without blocking merge of the wider feature.

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.

[skydhash]

The UI may be cluncky in the PR page, but I just use rebase, edit the commits, and force push the whole branch. The PR is the unit from the business perspective, not from my computer environment. I don’t mind creating two PRs for stacked changes, then once the first is merged, rebase from the main branch and publish the second one. Comments can be used to explain the link.

[alfiedotwtf]

I think the confusion and angst comes from when someone has multiple unrelated commits, submits it as a single PR, and is then REVIEWED intermingled all at the same time!

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!

[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.