Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reinventing the pull request

lubeno.dev

Post reply on HN
Print view View original

51–60 of 96 posts

Re: Reinventing the pull request

#51

Post by steveklabnik »

petcat wrote: post #4

> Once you have the power to do a bunch of small self-contained changes, you want PRs to consist of one or two commits. You want to build on previous changes without needing to wait for them to be reviewed. Lubeno helps you to do exactly this. Why would I want to build on changes that haven't been reviewed and accepted? That's a good way to waste my time having to redo something because the foundation it was based on…

If your PRs are more than one commit, you've already introduced work that builds on top of previous work before it's been reviewed.

Stacked diffs just let you review one commit at a time, rather than requiring a full review of the entire thing, while still letting you see that these changes are related, so you can go look at the full context if you'd like.

This lets you do things like "hey, backend person, please review this backend commit, frontend person, please review this frontend commit" instead of "both of you review this full PR". This can save the frontend person time if, for example, the frontend code passes review, but the backend reviewer hasn't had time to review the backend changes yet. They won't be pinged by the other review.

Re: Reinventing the pull request

#52

Post by steveklabnik »

MyHonestOpinon wrote: post #47

Regarding 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…

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.

Re: Reinventing the pull request

#53

Post by 6DM »

I will say, I love the idea of re-thinking PR's in the age of AI. I think it will be needed and I don't see GitHub pulling it off. I think they will just double down on trying to get AI to review it for us.

I haven't signed up, but I'm not convinced the stacked PR's is a good route. This is mostly because I'm thinking about it in terms of how I work now, so maybe after a trial run I would see it differently. My experience with launching software is people don't want to change their workflows.

So the way I imagine how this would get used by real accounts is they will still review individual PR's and merge them in like normal and avoid doing stacked PR's because a lot of us mostly care about the final result and less about the how you got there.

That is until we need to understand the how lol So being able to visualize this is probably a very useful tool for retroactive inspection over being part of the PR review workflow.

I hope the author doesn't feel like I'm dunking on them, I really love the idea of re-thinking PR.

Re: Reinventing the pull request

#54

Post by IshKebab »

steveklabnik wrote: post #49
esafak wrote: post #46

Earlier quoted context omitted.

link?

https://x.com/jaredpalmer/status/2019817235163074881 (this was a follow-up to the initial announcement months ago, also made via X)

Ah nice! I hope this actually works across repos rather than just being nicer UI for the existing functionality.

Re: Reinventing the pull request

#57

Post by steveklabnik »

jFriedensreich wrote: post #55

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

Re: Reinventing the pull request

#58

Post by huflungdung »

MyHonestOpinon wrote: post #47

Regarding 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…

[dead]

Re: Reinventing the pull request

#59

Post by sharts »

steveklabnik wrote: post #52
MyHonestOpinon wrote: post #47

Regarding 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…

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

Re: Reinventing the pull request

#60

Post by gib444 »

MyHonestOpinon wrote: post #47

Regarding 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…

What does the full story look like in your preferred approach? Regarding releasing for example
Post reply on HN