Stacked diffs let you not have to evaluate the whole PR as a whole, and encourages smaller and more frequent commits.
replyBasically, I agree with you that large PRs are a problem, I just don't think it means you need to throw pre-land code review out the window.
Agree too bad stacked PRs aren’t really native to GH and you probably need to go with not so standard tools to manage them
replyYes, it is unfortunate. I did link an announcement below that some form of this feature is coming, we'll see what it actually looks like when it goes public.
replyModern software engineering culture is a treadmill ever in search of the next best practice that must be applied to a field made up of bespoke scenarios.
replyThat's pretty much how Google does dev, though not everyone there is consistent about small CLs or the <24 hour SLO for code review.
replyBut yeah, if the team lead is aware of what everyone is working on, and prioritizes fast CLs review, huge amounts of friction and slowdown are removed from the process
What I’ve seen is things like I ask a question about a piece of code during a PR, the author changes that code and my question vanishes into the ether with no indication (unless it’s lost in the noise of email notifications) that the code was changed and my question is no longer relevant (and if there was, perhaps an answer, the answer is also lost).
replyYes. This specific aspect of GitHub is the reason why many teams don't want you to modify commits, but instead, add more commits. Which then also leads to squash-merging branches.
replyOther systems, like Gerrit, handle this much better!
deleted
replythis is how we work using graphite
replyWhat does the full story look like in your preferred approach? Regarding releasing for example
reply[dead]
reply