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

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.

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.

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.

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.

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.

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.

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.

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/

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.

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

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.

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.

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.

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

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?

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)

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.

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

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

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

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.

> you spend a LOT of time trying to get your PR reviewed.

I've fixed this issue in several teams I've joined. Maybe some people won't understand this, as I didn't until I observed it multiple times over.

There are teams out there, perhaps the majority, that simply leave the decision as to when a PR will be reviewed nebulous, and at the discretion of team members. There is no formal obligation to do them in a timely manner, and there are no consequences if they are not done.

The solve to this is obvious and easy:

- Automatically assign specific people to PRs. No general team assignment. The submitter can add specific people in addition to PR's if they need domain experts, but the normal case is random assignment.

- Require PR's to be done within 24 working hours. If you cannot do this for whatever reason, you must communicate this to the team.

- There are consequences if you violate this policy.

The last one is the hard part for cowardly teams and cowardly managers. You do have to stay on top of it initially, and even when people have accepted this and gotten used to it, you can't forget about it because people will drift.

This isn't to say I'm against the direct integration model you propose, I can also see the appeal, it's just that problems with PR flows are mostly about cowardly management, not anything much to do with the actual process.

That's pretty much how Google does dev, though not everyone there is consistent about small CLs or the <24 hour SLO for code review.

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

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.

PRs can contain multiple commits. You need something like stgit to make it easy to make a bunch of small commits that appear to be the work of an omniscient genius who knew exactly what they were doing. Try using stgit for awhile, and you'll wonder how you ever lived without it.

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

this is how we work using graphite