Earlier quoted context omitted.
GitHub is putting stacked PRs into private beta around now, actually.
link?
https://github.com/github/roadmap/issues/1218 is the tracking issue for it
Reinventing the pull request
61–70 of 96 posts
Re: Reinventing the pull request
#62Regarding PRs. I have a an opinion which has become very unpopular since the rise of github. The way github does PRs is great for open source projects where you have submissions from a very diverse set of developers. You need to evaluate the whole PR as whole and accept it or reject it. But it is not ideal where you have a small team working on single product. The PR review becomes a gate and it has been my experienc…
That's pretty much how Google does dev, though not everyone there is consistent about small CLs or the But 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
Re: Reinventing the pull request
#63Regarding PRs. I have a an opinion which has become very unpopular since the rise of github. The way github does PRs is great for open source projects where you have submissions from a very diverse set of developers. You need to evaluate the whole PR as whole and accept it or reject it. But it is not ideal where you have a small team working on single product. The PR review becomes a gate and it has been my experienc…
[deleted]
Re: Reinventing the pull request
#64Earlier quoted context omitted.
Stacked diffs let you not have to evaluate the whole PR as a whole, and encourages smaller and more frequent commits. Basically, 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
Yes, 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.
Re: Reinventing the pull request
#65i think the time is just over where i would consider a saas for code review instead of a local first tool that i can use for my local agents exactly the same way as for my colleagues right where i build the software not on some website.
How do you communicate the results of this review to your colleagues? (This is a genuine question, I think local first review is very interesting, but at some point, you've gotta send that feedback to the person you're reviewing.)
Ideally via the git host in something like a gerrit compatible git notes object.
Re: Reinventing the pull request
#66Earlier quoted context omitted.
How do you communicate the results of this review to your colleagues? (This is a genuine question, I think local first review is very interesting, but at some point, you've gotta send that feedback to the person you're reviewing.)
Ideally via the git host in something like a gerrit compatible git notes object.
Cool! That makes sense. I appreciate it.
Re: Reinventing the pull request
#67Regarding PRs. I have a an opinion which has become very unpopular since the rise of github. The way github does PRs is great for open source projects where you have submissions from a very diverse set of developers. You need to evaluate the whole PR as whole and accept it or reject it. But it is not ideal where you have a small team working on single product. The PR review becomes a gate and it has been my experienc…
this is how we work using graphite
Re: Reinventing the pull request
#68Regarding PRs. I have a an opinion which has become very unpopular since the rise of github. The way github does PRs is great for open source projects where you have submissions from a very diverse set of developers. You need to evaluate the whole PR as whole and accept it or reject it. But it is not ideal where you have a small team working on single product. The PR review becomes a gate and it has been my experienc…
That's pretty much how Google does dev, though not everyone there is consistent about small CLs or the But 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).
Re: Reinventing the pull request
#69Earlier quoted context omitted.
That's pretty much how Google does dev, though not everyone there is consistent about small CLs or the But 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).
Yes. 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.
Other systems, like Gerrit, handle this much better!
Re: Reinventing the pull request
#70Let's forget that this post is an ad. I feel like there is a use for LLMs that could help us do stacked PRs better. Right now there are effectively three ways to do a PR: - a bunch of small commits, some of them related to the feature, some fixes, some mixing both -> a PR with 'n' commits -> they don't really make sense as atomic commits, you have to review the entire PR to make the sense of it - a squashed PR - some…
The last option is absolutely not unreasonable to expect people to do by hand, as the article states it’s simply a problem of tooling. JJ makes this extremely easy to do, but some of us have been doing just the same in git for a long time and it is extremely achievable once you know your way around a rebase.
It's like switching to jujutsu gives people some kind of mental permission to do this - jujutsu justifies its existence just by that alone, really.