26
top 16 comments
sorted by: hot top new old
[-] Miaou@jlai.lu 3 points 5 days ago* (last edited 5 days ago)

I've recently picked up jujutsu, and it plus gitlab's stacked PR have made splitting up MRs a breeze. Typo in a commit at the top of the chain? "jj edit revision", fix the typo, then "jj git push".

[-] FizzyOrange@programming.dev 1 points 5 days ago

Do you mean GitHub? Last I checked Gitlab doesn't support stacked PRs.

[-] Miaou@jlai.lu 1 points 5 days ago

No I meant gitlab. I have been using them for a week or two now, I guess it's a recent addition

[-] FizzyOrange@programming.dev 1 points 4 days ago

Ah yeah looks like the latest 19.1 release from June.

But it also seems to suggest it's only a UI change. Is is possible to do stacked MRs across forks? Does it not still suffer from the flaw GitHub has (or had, hopefully) - you create one MR, myfork:feature_0 -> upstream:master. That's fine, but then you want to create the second MR targeting the first MR, myfork:feature_1 -> ???:feature_0, only you can't. feature_0 doesn't exist in the upstream and there's no point creating an MR targeting your own fork.

[-] nark3d 2 points 5 days ago

This looks useful for keeping a long change reviewable without leaving a branch open for a fortnight. Most of my pain with big PRs was never the size of the diff, it was that it had been diverging from main for two weeks before anyone opened it.

The discipline doesn't go away though, it just moves. If the bottom of the stack sits unmerged you still have a long-lived branch, with everything else stacked on top of it.

[-] blackn1ght@feddit.uk 3 points 6 days ago

Maybe I'm being dumb but I don't see the point? Just be disciplined in creating smaller PRs?

[-] tatterdemalion@programming.dev 5 points 5 days ago

That is the point. By making smaller PRs, you inevitably end up with dependencies between them. So you'd like to stack them.

[-] blackn1ght@feddit.uk 1 points 5 days ago

Maybe I just don't know enough how these work, as I've never heard of stacked prs before.

What does the workflow look like? Can the first PR be merged and deployed without the other prs being approved and merged first? Or do they all need to be approved and it all gets merged together?

[-] FizzyOrange@programming.dev 2 points 5 days ago

I haven't used it yet but assuming they did it right, yes you can merge the PRs sequentially.

[-] Miaou@jlai.lu 2 points 5 days ago

Assuming it's like gitlab's stacked PRs, all the merge requests are independent. It's basically "just" rebasing the stack once the bottom gets merged.

[-] panda_abyss@lemmy.ca 4 points 6 days ago

Isn’t that what this does? You do a bunch of small PRs then stack them into the full feature

[-] ftp@feddit.uk 4 points 6 days ago

We’re keen to use stacked PRs at work.

We’re using agentic coding heavily, but still reviewing code to help us steer the software architecture and keep our understanding of the implementation. We generate large changes quickly, but need to break them into smaller, logically ordered PRs for review.

It’s nice for the reviewer to be able to look ahead through the full change, so they see can check the big picture, rather than merging a couple of PRs and then spotting that the abstractions are wrong.

PR stacks work very well for providing this kind of visibility, but are annoying to merge. After one PR in the stack is merged, the next PR needs to be rebased onto and targeted to the updated main branch. With our branch protection rules, this triggers another CI run and dismisses the PR approval, requiring human intervention.

It would be much nicer to have the reviewer go through all the PRs and then merge the stack in one go.

[-] sanitation@lemmy.today -1 points 1 week ago

im not sure if I care tbh. seems gimmicky

[-] Dunstabzugshaubitze@feddit.org 6 points 6 days ago

It seems like something we allready do at work, with feature-branches that collect multiple prs that are required for a feature, but with some proprietary bits and bops instead of an internal procedure and standard git features.

i guess it's nice for people who use github in their team, but it furthers lock-in.

[-] kauraaaa@sopuli.xyz 2 points 6 days ago

agreed, happens in our org quite often as well previously just done via separate chained PRs and required rebasing after each merge

that describes everything github does these days

this post was submitted on 31 Jul 2026
26 points (88.2% liked)

Programming

27973 readers
287 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS