Sorry, “dodge” was a loaded word. I suppose what I mean is, what’s the difference between a PR with multiple commits and a commit with multiple commits?
I’m not sure what a “commit with multiple commits” is. I direct we’re talking past each other slightly :)
I think this is maybe what you’re asking about: with PRs, you often respond to feedback by adding new commits on to the PR. This is because code review is based on reviewing an entire branch. In a stacked diff based system, you respond to feedback by amending the commit. This is because reviews are tied to individual commits, not branches.
The reason people prefer this is that it keeps changes small and focused, and makes sure you have a high quality history. It also lets you assign different reviewers to different parts of your stack, which is helpful for all sorts of reasons. It also means that you can land earlier commits while waiting on review for the later commits, instead of holding it all up at once. Lots of stuff like this.
Any time. This stuff took me a while to wrap my head around, since I never worked at Google or Meta. I don't think I'm the best at explaining it yet either...
Ha, yeah. I worked at Box.com for a couple years and it took me months to figure out why my giant PRs full of genius were getting so much pushback. Just two different workflows depending on scale.
Comments
Sorry, “dodge” was a loaded word. I suppose what I mean is, what’s the difference between a PR with multiple commits and a commit with multiple commits?
I’m not sure what a “commit with multiple commits” is. I direct we’re talking past each other slightly :)
I think this is maybe what you’re asking about: with PRs, you often respond to feedback by adding new commits on to the PR. This is because code review is based on reviewing an entire branch. In a stacked diff based system, you respond to feedback by amending the commit. This is because reviews are tied to individual commits, not branches.
The reason people prefer this is that it keeps changes small and focused, and makes sure you have a high quality history. It also lets you assign different reviewers to different parts of your stack, which is helpful for all sorts of reasons. It also means that you can land earlier commits while waiting on review for the later commits, instead of holding it all up at once. Lots of stuff like this.
Cool, thanks.
Any time. This stuff took me a while to wrap my head around, since I never worked at Google or Meta. I don't think I'm the best at explaining it yet either...
Ha, yeah. I worked at Box.com for a couple years and it took me months to figure out why my giant PRs full of genius were getting so much pushback. Just two different workflows depending on scale.