Reinventing the pull request • Hacker News Board

Re: Reinventing the pull request

#31

Post by radlad » Thu, Apr 02, 2026, 2:10 PM UTC

i_cannot_hack wrote: post #21

vermilingua wrote: post #14

Earlier quoted context omitted.

If you’re getting to the point where you’re submitting PRs if you don’t know whether the foundation of the change is flawed, you have more pressing issues than wasting time in code review fixes.

There's only a limited amount of context and decisions that can be effectively communicated informally without looking at the code. Sometimes it is required that people look at the actual suggested implementation, and when doing so they might spot fundamental issues that had not been found beforehand. The conventional format for doing such a review is a PR.

And thus, you don't have to build on every single unreviewed PR - but often it's quite sane to do so.

Re: Reinventing the pull request

#32

Post by shay_ker » Thu, Apr 02, 2026, 2:14 PM UTC

I'd love to see an example PR on lubeno vs github. That might show the comparison a bit better.

Re: Reinventing the pull request

#33

Post by patrickRyu » Thu, Apr 02, 2026, 2:35 PM UTC

[flagged]

Re: Reinventing the pull request

#34

Post by philipwhiuk » Thu, Apr 02, 2026, 2:41 PM UTC

It would be nice if I could click the images to make them larger. As is it's not actually possible to see anything novel being done.

Re: Reinventing the pull request

#35

Post by lapcat » Thu, Apr 02, 2026, 2:41 PM UTC

bkolobara wrote: post #28

lapcat wrote: post #5

This blog post is self-promotion, essentially an advertisement for a paid product, Lubeno, submitted by the developer of the product.

... on a website owned by the VC that invested in the developer. I believe that the ideas in the blog post are novel enough and should spark curiosity and interesting discussions. Also I submitted this last week, someone must have hand-picked and given it another chance because it's a good fit for HN.

> ... on a website owned by the VC that invested in the developer.

Thanks for disclosing the financial conflict of interest, but this doesn't change the self-promotion factor.

Re: Reinventing the pull request

#36

Post by bkolobara » Thu, Apr 02, 2026, 2:47 PM UTC

philipwhiuk wrote: post #34

It would be nice if I could click the images to make them larger. As is it's not actually possible to see anything novel being done.

Direct links to the images, until I implement popup on click:

https://lubeno.dev/assets/images/blog/lubeno-repository.png

https://lubeno.dev/assets/images/blog/lubeno-pr.png

https://lubeno.dev/assets/images/blog/code-review-before-aft...

Re: Reinventing the pull request

#37

Post by bkolobara » Thu, Apr 02, 2026, 2:51 PM UTC

shay_ker wrote: post #32

I'd love to see an example PR on lubeno vs github. That might show the comparison a bit better.

Lubeno only supports private repositories at the moment, so I can't link directly to one. But that is on my todo list.

Re: Reinventing the pull request

#38

Post by codexb » Thu, Apr 02, 2026, 2:53 PM UTC

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…

Because those changes might depend on those other changes. Git merges aren't linear. They're branched. And PR reviews are meant to just examine the merge of 1 branch back into master. They're not really meant to review multiple steps along the same branch to make it easier to review.

There are so many times where I want to create 3-4 Merge requests that all build on each other along the same branch instead of creating one giant MR but the UI for reviewing them doesn't really work that way.

Re: Reinventing the pull request

#39

Post by steveklabnik » Thu, Apr 02, 2026, 3:01 PM UTC

vermilingua wrote: post #15

The platform this is an ad for looks to be very bare-bones, but I’m still very glad to see a new entry in the code forge space focusing on stacked PRs since Graphite went all-in on clanker review. Extremely keen to see what will come out of ERSC [0] [0] https://ersc.io/

Just to be clear about it, we’re not “the stacked diffs company,” that is, we consider stacked diffs table stakes for good code review, not the entire point and focus of the product.

That said, we haven’t talked a ton publicly about what exactly we’re building yet, because we’re very focused on building it. But if you or anyone else is dealing with pain around source control management, I’d love to hear about it: steve@ersc.io

Re: Reinventing the pull request

#40

Post by steveklabnik » Thu, Apr 02, 2026, 3:05 PM UTC

sbszllr wrote: post #12

Let'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…

I have had good success lately with asking Claude to do your last option. jj also works fantastically for this, because you can easily jj new up a bunch of empty changes with the descriptions you want to have, and then jj restore the state from your original stack into them. If the process goes poorly for any reason, you still have your original stack around.

You don’t have to do it this way, you could use the oplog to undo it all if it’s not to your satisfaction, but it’s much simpler than trying to edit the commits into the right shape directly.