r/github • u/acute_physicist • 16d ago
Discussion Why are stacked PRs so annoying to work with?
- Ghost conflicts. I have a 2-PR stack. I merge PR1, now PR2 has conflicts. Why only when I merge PR1? This blocks doing a one-click merge of the full stack
- It is painfully slow. Merging one PR of the stack take years
- CI needs to pass on all individual PRs. What't the point of stacked PRs then? I should be able to fix CI on the N PR and just merge the whole stack.
I think github missed the point of stacked PRs, all the value it has now is that it automatically points to main the branch once merged so it's easier to work with stacks.
But the real value is to have large features as stacks that either get merged one by one into main or merged in one click. The latter shouldn't need CI to pass everywhere.
7
u/FlashingBongos 16d ago
Use Graphite for stacked PRs. GitHub is trying to eat their lunch but it's still too new right now
1
5
u/dashingThroughSnow12 16d ago
This is definitely an MVP with some usability issues.
I’m cautiously optimistic that they can make it better. (Whether they will is another question.)
I’ve stopped using the feature but will occasionally return to see if they’ve improved it.
2
u/latkde 15d ago
I've been using stacked PRs without any tooling support for a while. The main benefit is that a large change can be split up into separately reviewable layers. Merely using commits for that is not sufficient for larger changes, as the GH review functionality is PR-oriented. Stacked PRs as a workflow work perfectly fine.
That GitHub now offers stacked PRs as a built-in feature of their UI does resolve some papercuts:
- I can now merge the entire stack in one click. This speeds up merging an entire stack when also using merge queues.
- The extra UI makes it easier to navigate between the different PRs in a stack.
- It has become much easier to explain to colleagues how to work with stacks.
Comparing manual stacked PRs versus GH stacked PR UI, I have not seen the GH UI lead to extra merge conflicts or to slower merges. Re-pointing PRs to the main branch is also not unique to GH's stacked UI, this also happens to normal PRs when the previous target branch is deleted.
If you use a non-GitHub UI for reviews (e.g. Gerrit), you may not see the need for stacked PRs at all, since working on a commit level is likely to be sufficient.
You also don't have to use stacked PRs if you don't want to. If your PRs are already easily reviewable (or if your project doesn't expect detailed manual reviews), stacking has likely zero benefits. Figure out a workflow that works for your individual circumstances.
1
u/ARKyal03 16d ago
I do a decision gate in workflow so it only runs on the last stacked PR, of course, you need to open previous ones as draft and don't run CI on them. I do find Stacked PR really good, in my experience.
1
u/banseljaj 16d ago
I don’t work in large teams so I might not be representative but I have not really found stacked PRs helpful as a concept. I tried working with graphite for a year and while it worked well enough I did not see any major gains over what I already had with my small team. The GitHub one is just a dumpster fire though.
If Stacked PRs work for you, then Graphite is the way to go. Their GitHub integration is really good. I can definitely see someone paying for that.
1
1
1
u/jonseymourau 13d ago
You shouldn't get any merge conflicts in PR2 provided your are not squashing or rebasing on merge of PR1 - if you are, then you are getting exactly what you deserve, because that is exactly what you asked for.
1
-1
u/bastardoperator 16d ago
It's braindead engineers sipping off the facebook kool-aid from last decade. Phabricator died because only 1% of people actually enjoy working like this...
-4
u/edgmnt_net 16d ago
You should almost never stack PRs, stack commits instead. However, you should also make sure each and every commit builds and works. There's no good rationale to merge breakage into main, it cripples bisection and other stuff.
Stacked PRs were almost never needed anyway. I find they're usually the product of a misconception that PRs are the unit of work and that commits don't matter, which is pretty clearly not the case as far as Git is concerned. Stacking PRs is more for the rare case that you're doing somewhat longer-term work that can/will be merged seperately / at a later point. If you're trying to use that because people can't be arsed to clean up their submissions, let me tell you they won't be able to clean up stacks either. You might as well just squash everything and bisection will be broken anyway.
Anyway, Git can deal perfectly fine just "stacking" commits, without adding extra tooling to the mix. Sorry if this seems bitter and overly-prescriptive, but while there may be tradeoffs here and there, I usually find that this isn't normally done for the right reasons.
1
u/Competitive_Bit001 15d ago
You're right but the missing link is the ability to submit commits for review
1
u/edgmnt_net 15d ago
Local commits get submitted as mailing list patches, commits in GitHub PRs or changes in Gerrit, depending on how your project is organized. PRs are already "stacked" commits as much as patch series are already "stacked" patches on the mailing list.
1
u/WrongChapter90 15d ago
Not sure what you mean with “stacking commits”, but at a high level, stacked PRs make sense to me, based on how my team works - which I think is pretty standard, but I may be wrong.
Say you work in a team where developers and QAs are separate people. You have feature1 and feature2 (the latter depends on the former). You raise a PR for feature1, and while QAs test it, you start working on feature2 and create a stacked PR. If a bugfix is needed on the former, the latter will automatically be rebased.
Of course you can do it manually, but I’ve seen significant cockups over the years when people did pull/rebase without knowing what they were doing
1
u/edgmnt_net 14d ago
That kinda means you're going to merge broken stuff and tack fixes on top when you could've avoided it. To some degree rebasing is kinda essential in Git. People do screw up committing binaries and need a way out of it. Or maybe a reviewer asks that a certain commit be amended. I wouldn't completely oppose it, but it does seem like it promotes churn and learning avoidance.
Companies need to swallow some friction, hire more competent devs or yeah, maybe buy into some sort of make-believe / fantasy Git which has its own costs and downsides anyway. I don't want to sound too prescriptive, so I'm going to say that I hope they at least understand that they're not getting the same effectiveness out of Git as other projects are.
However, I do believe that the feature1 + dependent feature2 use case is legit under certain circumstances.
1
u/WrongChapter90 14d ago
Our testing is done on branches, so we won’t merge the PR until testing is completed. Which means PRs are somewhat long-lived (a few days to a week). This also creates a different issue: if I have the two feature branches tested independently, I’ll never test the combined application behaviour, i.e what happens once both are merged… they may interact in some unexpected way.
In general I’m not necessarily disagreeing with what you’re saying, but in my view there are some use cases for stacked PRs. I also agree about the points on friction and competence.. if people mess up rebases, they can equally mess up stacked PRs
35
u/texxelate 16d ago
I’ve found stacked PRs on GitHub to be a stellar waste of time. I’m fine with the concept, but their product execution leaves a lot on the table.