4 ms·
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 chu
by 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 agoThe 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 agoI 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!