6 ms·

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 improvement

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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
> 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.
- nchmy 1y ago
  Jj makes this effort vastly easier. Nearly frictionless.
  - normie3000 1y ago
    Great. As I said elsewhere on this story, I'll suggest jj to colleagues who struggle with git.
    - globnomulous 1y ago
      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.
- UK-Al05 1y ago
  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.

jon-wood 1y ago

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 1y ago
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 1y ago
  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 1y ago

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

nchmy 1y ago
Jj makes this effort vastly easier. Nearly frictionless.
- normie3000 1y ago
  Great. As I said elsewhere on this story, I'll suggest jj to colleagues who struggle with git.
  - globnomulous 1y ago
    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.
UK-Al05 1y ago
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.