10 ms·

Reinventing the pull request

109 points by bkolobara 6mo ago

Jeffrin-dev 5mo ago
[dead]
Shank 6mo ago
On my first load of this page, it took 4.85 seconds to get meaningful content and the whole page took 8.09s. The vast majority of the delay seems to be from assets like the PNG images and the fonts, which don't seem to be on a CDN. I am located in Tokyo, Japan, with a 1Gbps symmetric connection, so while I am regionally quite distant from the site, I assume, I still think there are ample CDNs available that would speed this up.
- 6031769 6mo ago
  Lucky you. Blog.js fails for me with a TypeError and I'm disinclined to debug someone else's javascript on a whim, so I don't get to see any of the content at all. To the OP: JS is for enhancements. If you are using it in such a way that it becomes a potential blocker for all of the content then you are not going to reach the audience that you otherwise would. If you are on somebody else's platform/framework then by all means pass this up the chain.
- taspeotis 6mo ago
  Mobile is particularly bad https://pagespeed.web.dev/analysis/https-lubeno-dev-blog-reinventing-the-pull-request/12a9907gmb?form_factor=mobile https://pagespeed.web.dev/analysis/https-lubeno-dev-blog-rei...
- bkolobara 6mo ago
  Sorry about that! Performance is really important to me, I just didn't get around to configuring CDN caching and optimizing the assets. All the HN traffic hitting our server also didn't help.
  - widdershins 6mo ago
    I signed up and I'm finding browsing a repo quite snappy. Good job.
epage 6mo ago
I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent. I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed. I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis. There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.
petcat 6mo ago
> 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 was flawed and got rejected later. There's a reason git and most accepted development workflows are linear.
- Vinnl 6mo ago
  Often it's very likely that previous ones won't need to change significantly, in which case disposing of having the full context while waiting for that review ends up slowing you down a lot. In those cases, often the main cause of extra busywork is Git administration, having to manually rebase sub-branches, and then losing in-progress reviews on those PRs as well.
- vermilingua 6mo ago
  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.
  - i_cannot_hack 6mo ago
    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.
    - radlad 6mo ago
      And thus, you don't have to build on every single unreviewed PR - but often it's quite sane to do so.
- 6mo ago
lapcat 6mo ago
This blog post is self-promotion, essentially an advertisement for a paid product, Lubeno, submitted by the developer of the product.
- bkolobara 6mo ago
  ... 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.
  - lapcat 6mo ago
    > ... 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.
siruwastaken 6mo ago
I apreciate the fact that they mention that sometimes a commit change needs a fix before it ever even was pull-request ready. I think it would be great to have the ability to easily reorder/modify commits while in active development, and then lock them into permanent history afterwards. Apparently (according to the article) Jujutsu can do that, but I've never had personal exoerience with that VCS.
- fl0ki 6mo ago
  > I think it would be great to have the ability to easily reorder/modify commits while in active development Take a look at `git rebase --interactive`.
  - eviks 6mo ago
    That's not "easily". Easily would be: you drag your commit(s) from one place to another or copy/paste to achieve the same
    - fl0ki 6mo ago
      If that's the kind of UX you prefer, please consider filing a feature request against your git UI of choice. My point is that git itself already has the core capability, and how convenient it is to use usually depends on your editor. (e.g. in vim, dd to cut a line and p to paste it in a new position is a very quick way to reorder)
      - eviks 6mo ago
        And my point is that all this 'core capability' stuff is not relevant to the discussion of good UI, similarly the fact that GitHub has Pull Requests doesn't help when it's bad UI that needs "stack" reinventing. Case in point: > dd to cut a line and p to paste it in a new position is a very quick way to reorder) It isn't quick, you're just swiping the whole issue under the rug - first, you need the whole separate interface, but more importantly, this new interface is very primitive, you see close to no context, only some commit names, so it's not quick to find what to move and where because the content for those decisions is in a different place. Sure, you could add some vim plugin that expands it and adds per-commit info (what, you want to view the diff for all 3 commits you selected and DDed? Tough luck, you don't see the lines anymore! And even if you did, that's not this plugin), but then it's not your `--interactive` git "core" that does convenience
Hendrikto 6mo ago
This is just an ad.
Vinnl 6mo ago
Jujutsu is interesting in that it appeals both to Git enthusiasts, and people who strongly dislike Git's UX. It's great to see it spurring more innovation in the ecosystem around it. Though if it can just make stacked PRs widespread, I'd already be very happy.
sbszllr 6mo ago
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 uber principled reorganisation of commits that separates key implementation concerns into smaller commits (effectively stacked PRs but clean) The last option would be desirable but it's unreasonable to expect anyone to do it by hand. So this is where <maybe> an LLM could parse my garbage intermediate commits, the final diff and generate a stack instead?
- vermilingua 6mo ago
  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.
  - sbszllr 6mo ago
    Maybe it just shows my lack of tolerance for process/overhead. As a fellow rebase enjoyer, I will do it occasionally for smaller PRs but to me, it becomes unwieldy for large ones. Do you have any tips or aliases that makes it more workable?
    - vermilingua 6mo ago
      Yep, ensuring RERERE and autostash are enabled eliminate 80% of the tedium for me, but honestly just try jj; it seriously is a gamechanger and (so far, in ~6mth of use) it has had literally zero drawbacks in comparison to git, because it is still git and if I don’t know how to do something with jj, I can use the git commands I do know and it Just Works™
  - juped 6mo ago
    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.
vermilingua 6mo ago
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/ https://ersc.io/
- steveklabnik 6mo ago
  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
tfrancisl 6mo ago
I work in between two teams that would prefer no code review except for by pair programming (militantly arguing that this is the only true trunk based development, those small PRs are something else) and a team that every individual wants to own the dev cycle end to end. So its either pushes to main youre forced to catch up on that you had no alerts or knowledge of, or +6000 -500 diff PRs with way too many features and no story to tell in the commits. Maybe this tool would help, but nothing in this pitch convinces me.
IshKebab 6mo ago
It blows my mind that Github still doesn't support stacked PRs. Do they never do work that depends on an open PR? Like, as soon as they open a PR they're like "right, better stop doing anything until it's merged"? The file priority thing is a great idea too. That would be even more useful for search. The number of times I'm searching for something on Github and it just shows me a gazillion tests.... Yeah you can look up their advanced search syntax and exclude them probably, but it's always a hassle.
- jmalicki 6mo ago
  You can manually stack PRs by making the merge target another branch. The workflow just makes it a pain, since you have to manually rebase in both the branch and the UI after the original PR merges.
  - IshKebab 6mo ago
    That doesn't work if the base and PR branch are in different repos, which is the most common way of doing things in Github.
    - justinclift 6mo ago
      When the base and PR branch are in different repos, it'll still work if the PR branch's repo is a fork of the base one.
      - IshKebab 6mo ago
        No it doesn't. Here's the situation. You have an upstream repo github.com/fancyproject/fancyproject. You fork it to github.com/yourname/fancyproject. You make a branch `feature_0`, push it to yourname/fancyproject. Make a PR. Next you create another branch `feature_1`, based on `feature_0`. You push `feature_1` to yourname/fancyproject. There is now no way to make a PR for `feature_1` that includes only the changes from feature_0 to feature_1. You can't do it because when you create the PR (in fancyproject/fancyproject) you can't select `feature_0` as a base branch because that branch doesn't exist in fancyproject/fancyproject.
andsoitis 6mo ago
I wonder how may engineers contribute to their code base on a daily basis.
arafeq 6mo ago
[flagged]
shay_ker 6mo ago
I'd love to see an example PR on lubeno vs github. That might show the comparison a bit better.
- bkolobara 6mo ago
  Lubeno only supports private repositories at the moment, so I can't link directly to one. But that is on my todo list.
patrickRyu 6mo ago
[flagged]
philipwhiuk 6mo ago
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.
- bkolobara 6mo ago
  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-repository.png https://lubeno.dev/assets/images/blog/lubeno-pr.png https://lubeno.dev/assets/images/blog/lubeno-pr.png https://lubeno.dev/assets/images/blog/code-review-before-after.png https://lubeno.dev/assets/images/blog/code-review-before-aft...
woeirua 6mo ago
There’s an interesting nugget of an idea in this ad. But the current implementation leaves a lot to be desired. What I want out of the PR interface is to be able to ask an agent questions and get back supported answers and to be able to easily see the changes live in a system so I can test them. That requires solving a huge problem of iterative deployments but if you could do that the value of stacked PRs would be immense. If someone doesn’t do this then PRs will just be abandoned.
- dbbk 6mo ago
  There's a much more interesting idea that I'm waiting for somebody to do, which is just have AI break down a PR into digestible chunks for me. Stacked PRs are a nice idea but they require the developer to follow the pattern. I'd rather be able to get a big 50+ file PR, and have it be broken down into bite size areas I can review and check along as I go. This would be especially helpful for mobile, where reading a traditional diff is basically impossible.
  - afro88 6mo ago
    This is a really good idea. Especially if the chunks are marked as read as you are guided through them and you can validate you've seen all the code by the end
fogzen 6mo ago
I don’t want to reinvent the pull request. I want to commit to main like an adult.
MyHonestOpinon 6mo ago
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 experience as a developer that you spend a LOT of time trying to get your PR reviewed. My preferred approach is to do smaller and more frequent commits that are merged directly to the main branch. Developers learn to break a problem into very small changes which is a skill by itself. It is the responsibility of a lead or Sr engineer to check the commits as they come so they can provide feedback as soon as possible. This was the spirit of the original continuous integration ideas back in the day.
- deleted 6mo ago
  [deleted]
- gdulli 6mo ago
  Modern 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.
- steveklabnik 6mo ago
  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.
  - sharts 6mo ago
    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
    - steveklabnik 6mo ago
      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.
6DM 6mo ago
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.
jFriedensreich 6mo ago
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.
- steveklabnik 6mo ago
  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.)
  - jFriedensreich 6mo ago
    Ideally via the git host in something like a gerrit compatible git notes object.
    - steveklabnik 6mo ago
      Cool! That makes sense. I appreciate it.
ceayo 6mo ago
> Reinventing the pull requests I've got some wheels spare, care to have some?
rheakapoor 6mo ago
[dead]
jtbetz22 6mo ago
> So even when you have a nicely structured commit history, you end up realizing that some things need to be changed and start appending a bunch of "fix" and "actual fix" commits at the end. I have found that this no longer needs to be an issue with agentic coding tools. Once I am happy with the end state of a branch, I tell Claude to rebuild the change from scratch as a set of atomic incremental commits. It adds about 2 minutes to the dev process, but creates a pr that is infinitely easier to review. The overall thrust of the article is great, though. The tooling around prs needs a ton of attention.
- deleted 6mo ago
  [deleted]
- demorro 6mo ago
  It takes barely longer than that to do manually, the extra time really just being the typing out of the commit messages. Folks should have been doing this all along and it still shocks me to discover that they haven't been. However, I don't immediately dislike the idea of people using agents to do it, even though I'm sure it will occasionally introduce some strange choices and not fully capture the intention behind any given choice.
sdevonoes 6mo ago
Are devs really reviewing AI generated code? It just seems so pointless. Nobody was reviewing protoc generated code, for example, and most of my colleagues (not faang, but one level below) simply comment “LGTM!” or equivalents when a PR smells like ai generated code. Seems fair. Even more so if I add a comment to a PR and what I get in reply is an AI generated reply with AI generated commit (you can tell also because of the “Coauthor Claude” thingy in the commit)
- SkiFire13 6mo ago
  > Nobody was reviewing protoc generated code Are you seriously comparing LLMs with a deterministic code generator?
- justinclift 6mo ago
  > Are devs really reviewing AI generated code? Definitely. Even the current leading edge AI models (ie Claude Code Opus 4.6 (1M)) gets things (badly) wrong occasionally, makes bad decisions, and does stupid stuff. It's a lot better than even just a few months ago, but blinding accepting its output for code that matters will catch you out.
demorro 6mo ago
This whole thread reads like skill issues, sorry to say. This presumption that you have to stop work whilst you wait on a PR to be reviewed is absurd. Rebasing is not this impossible challenge and if it's stopping you making progress you need to grow up.

109 points by bkolobara 6mo ago

[dead]

Shank 6mo ago

On my first load of this page, it took 4.85 seconds to get meaningful content and the whole page took 8.09s. The vast majority of the delay seems to be from assets like the PNG images and the fonts, which don't seem to be on a CDN. I am located in Tokyo, Japan, with a 1Gbps symmetric connection, so while I am regionally quite distant from the site, I assume, I still think there are ample CDNs available that would speed this up.

6031769 6mo ago
Lucky you. Blog.js fails for me with a TypeError and I'm disinclined to debug someone else's javascript on a whim, so I don't get to see any of the content at all. To the OP: JS is for enhancements. If you are using it in such a way that it becomes a potential blocker for all of the content then you are not going to reach the audience that you otherwise would. If you are on somebody else's platform/framework then by all means pass this up the chain.
taspeotis 6mo ago
Mobile is particularly bad https://pagespeed.web.dev/analysis/https-lubeno-dev-blog-reinventing-the-pull-request/12a9907gmb?form_factor=mobile https://pagespeed.web.dev/analysis/https-lubeno-dev-blog-rei...
bkolobara 6mo ago
Sorry about that! Performance is really important to me, I just didn't get around to configuring CDN caching and optimizing the assets. All the HN traffic hitting our server also didn't help.
- widdershins 6mo ago
  I signed up and I'm finding browsing a repo quite snappy. Good job.

epage 6mo ago

I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent. I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed. I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis. There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.

petcat 6mo ago

> 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 was flawed and got rejected later. There's a reason git and most accepted development workflows are linear.

Vinnl 6mo ago
Often it's very likely that previous ones won't need to change significantly, in which case disposing of having the full context while waiting for that review ends up slowing you down a lot. In those cases, often the main cause of extra busywork is Git administration, having to manually rebase sub-branches, and then losing in-progress reviews on those PRs as well.
vermilingua 6mo ago
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.
- i_cannot_hack 6mo ago
  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.
  - radlad 6mo ago
    And thus, you don't have to build on every single unreviewed PR - but often it's quite sane to do so.
6mo ago

lapcat 6mo ago

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

bkolobara 6mo ago
... 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.
- lapcat 6mo ago
  > ... 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.

siruwastaken 6mo ago

I apreciate the fact that they mention that sometimes a commit change needs a fix before it ever even was pull-request ready. I think it would be great to have the ability to easily reorder/modify commits while in active development, and then lock them into permanent history afterwards. Apparently (according to the article) Jujutsu can do that, but I've never had personal exoerience with that VCS.

fl0ki 6mo ago
> I think it would be great to have the ability to easily reorder/modify commits while in active development Take a look at `git rebase --interactive`.
- eviks 6mo ago
  That's not "easily". Easily would be: you drag your commit(s) from one place to another or copy/paste to achieve the same
  - fl0ki 6mo ago
    If that's the kind of UX you prefer, please consider filing a feature request against your git UI of choice. My point is that git itself already has the core capability, and how convenient it is to use usually depends on your editor. (e.g. in vim, dd to cut a line and p to paste it in a new position is a very quick way to reorder)
    - eviks 6mo ago
      And my point is that all this 'core capability' stuff is not relevant to the discussion of good UI, similarly the fact that GitHub has Pull Requests doesn't help when it's bad UI that needs "stack" reinventing. Case in point: > dd to cut a line and p to paste it in a new position is a very quick way to reorder) It isn't quick, you're just swiping the whole issue under the rug - first, you need the whole separate interface, but more importantly, this new interface is very primitive, you see close to no context, only some commit names, so it's not quick to find what to move and where because the content for those decisions is in a different place. Sure, you could add some vim plugin that expands it and adds per-commit info (what, you want to view the diff for all 3 commits you selected and DDed? Tough luck, you don't see the lines anymore! And even if you did, that's not this plugin), but then it's not your `--interactive` git "core" that does convenience

Hendrikto 6mo ago

This is just an ad.

Vinnl 6mo ago

Jujutsu is interesting in that it appeals both to Git enthusiasts, and people who strongly dislike Git's UX. It's great to see it spurring more innovation in the ecosystem around it. Though if it can just make stacked PRs widespread, I'd already be very happy.

sbszllr 6mo ago

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 uber principled reorganisation of commits that separates key implementation concerns into smaller commits (effectively stacked PRs but clean) The last option would be desirable but it's unreasonable to expect anyone to do it by hand. So this is where <maybe> an LLM could parse my garbage intermediate commits, the final diff and generate a stack instead?

vermilingua 6mo ago
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.
- sbszllr 6mo ago
  Maybe it just shows my lack of tolerance for process/overhead. As a fellow rebase enjoyer, I will do it occasionally for smaller PRs but to me, it becomes unwieldy for large ones. Do you have any tips or aliases that makes it more workable?
  - vermilingua 6mo ago
    Yep, ensuring RERERE and autostash are enabled eliminate 80% of the tedium for me, but honestly just try jj; it seriously is a gamechanger and (so far, in ~6mth of use) it has had literally zero drawbacks in comparison to git, because it is still git and if I don’t know how to do something with jj, I can use the git commands I do know and it Just Works™
- juped 6mo ago
  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.

vermilingua 6mo ago

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/ https://ersc.io/

steveklabnik 6mo ago
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

tfrancisl 6mo ago

I work in between two teams that would prefer no code review except for by pair programming (militantly arguing that this is the only true trunk based development, those small PRs are something else) and a team that every individual wants to own the dev cycle end to end. So its either pushes to main youre forced to catch up on that you had no alerts or knowledge of, or +6000 -500 diff PRs with way too many features and no story to tell in the commits. Maybe this tool would help, but nothing in this pitch convinces me.

IshKebab 6mo ago

It blows my mind that Github still doesn't support stacked PRs. Do they never do work that depends on an open PR? Like, as soon as they open a PR they're like "right, better stop doing anything until it's merged"? The file priority thing is a great idea too. That would be even more useful for search. The number of times I'm searching for something on Github and it just shows me a gazillion tests.... Yeah you can look up their advanced search syntax and exclude them probably, but it's always a hassle.

jmalicki 6mo ago
You can manually stack PRs by making the merge target another branch. The workflow just makes it a pain, since you have to manually rebase in both the branch and the UI after the original PR merges.
- IshKebab 6mo ago
  That doesn't work if the base and PR branch are in different repos, which is the most common way of doing things in Github.
  - justinclift 6mo ago
    When the base and PR branch are in different repos, it'll still work if the PR branch's repo is a fork of the base one.
    - IshKebab 6mo ago
      No it doesn't. Here's the situation. You have an upstream repo github.com/fancyproject/fancyproject. You fork it to github.com/yourname/fancyproject. You make a branch `feature_0`, push it to yourname/fancyproject. Make a PR. Next you create another branch `feature_1`, based on `feature_0`. You push `feature_1` to yourname/fancyproject. There is now no way to make a PR for `feature_1` that includes only the changes from feature_0 to feature_1. You can't do it because when you create the PR (in fancyproject/fancyproject) you can't select `feature_0` as a base branch because that branch doesn't exist in fancyproject/fancyproject.

andsoitis 6mo ago

I wonder how may engineers contribute to their code base on a daily basis.

arafeq 6mo ago

[flagged]

shay_ker 6mo ago

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

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

patrickRyu 6mo ago

[flagged]

philipwhiuk 6mo ago

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.

bkolobara 6mo ago
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-repository.png https://lubeno.dev/assets/images/blog/lubeno-pr.png https://lubeno.dev/assets/images/blog/lubeno-pr.png https://lubeno.dev/assets/images/blog/code-review-before-after.png https://lubeno.dev/assets/images/blog/code-review-before-aft...

woeirua 6mo ago

There’s an interesting nugget of an idea in this ad. But the current implementation leaves a lot to be desired. What I want out of the PR interface is to be able to ask an agent questions and get back supported answers and to be able to easily see the changes live in a system so I can test them. That requires solving a huge problem of iterative deployments but if you could do that the value of stacked PRs would be immense. If someone doesn’t do this then PRs will just be abandoned.

dbbk 6mo ago
There's a much more interesting idea that I'm waiting for somebody to do, which is just have AI break down a PR into digestible chunks for me. Stacked PRs are a nice idea but they require the developer to follow the pattern. I'd rather be able to get a big 50+ file PR, and have it be broken down into bite size areas I can review and check along as I go. This would be especially helpful for mobile, where reading a traditional diff is basically impossible.
- afro88 6mo ago
  This is a really good idea. Especially if the chunks are marked as read as you are guided through them and you can validate you've seen all the code by the end

fogzen 6mo ago

I don’t want to reinvent the pull request. I want to commit to main like an adult.

MyHonestOpinon 6mo ago

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 experience as a developer that you spend a LOT of time trying to get your PR reviewed. My preferred approach is to do smaller and more frequent commits that are merged directly to the main branch. Developers learn to break a problem into very small changes which is a skill by itself. It is the responsibility of a lead or Sr engineer to check the commits as they come so they can provide feedback as soon as possible. This was the spirit of the original continuous integration ideas back in the day.

deleted 6mo ago
[deleted]
gdulli 6mo ago
Modern 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.
steveklabnik 6mo ago
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.
- sharts 6mo ago
  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
  - steveklabnik 6mo ago
    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.

6DM 6mo ago

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.

jFriedensreich 6mo ago

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.

steveklabnik 6mo ago
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.)
- jFriedensreich 6mo ago
  Ideally via the git host in something like a gerrit compatible git notes object.
  - steveklabnik 6mo ago
    Cool! That makes sense. I appreciate it.

ceayo 6mo ago

> Reinventing the pull requests I've got some wheels spare, care to have some?

rheakapoor 6mo ago

[dead]

jtbetz22 6mo ago

> So even when you have a nicely structured commit history, you end up realizing that some things need to be changed and start appending a bunch of "fix" and "actual fix" commits at the end. I have found that this no longer needs to be an issue with agentic coding tools. Once I am happy with the end state of a branch, I tell Claude to rebuild the change from scratch as a set of atomic incremental commits. It adds about 2 minutes to the dev process, but creates a pr that is infinitely easier to review. The overall thrust of the article is great, though. The tooling around prs needs a ton of attention.

deleted 6mo ago
[deleted]
demorro 6mo ago
It takes barely longer than that to do manually, the extra time really just being the typing out of the commit messages. Folks should have been doing this all along and it still shocks me to discover that they haven't been. However, I don't immediately dislike the idea of people using agents to do it, even though I'm sure it will occasionally introduce some strange choices and not fully capture the intention behind any given choice.

sdevonoes 6mo ago

Are devs really reviewing AI generated code? It just seems so pointless. Nobody was reviewing protoc generated code, for example, and most of my colleagues (not faang, but one level below) simply comment “LGTM!” or equivalents when a PR smells like ai generated code. Seems fair. Even more so if I add a comment to a PR and what I get in reply is an AI generated reply with AI generated commit (you can tell also because of the “Coauthor Claude” thingy in the commit)

SkiFire13 6mo ago
> Nobody was reviewing protoc generated code Are you seriously comparing LLMs with a deterministic code generator?
justinclift 6mo ago
> Are devs really reviewing AI generated code? Definitely. Even the current leading edge AI models (ie Claude Code Opus 4.6 (1M)) gets things (badly) wrong occasionally, makes bad decisions, and does stupid stuff. It's a lot better than even just a few months ago, but blinding accepting its output for code that matters will catch you out.

demorro 6mo ago

This whole thread reads like skill issues, sorry to say. This presumption that you have to stop work whilst you wait on a PR to be reviewed is absurd. Rebasing is not this impossible challenge and if it's stopping you making progress you need to grow up.