I've been using it for a while and I've actually shipped stacked PRs with github.
we usually try to chunk the work so that we don't get in a situation were we have to open PRs with more 1k+ LOC, and we try to plan chunks of max 500 LOC, but I do find myself getting in this situation when the planned work turns out to be more than I anticipated like refactoring or edge cases or review feedback... etc. but that's where stacked PRs come in, I found that they could be useful in this situation to split an unexpectedly large PR into a few smaller ones that are chunkable, individually shippable, and easy to review. but that's where the good stuff ends IMO, stacked PRs just make a bad situation slightly better, and I think we shouldn't get into this situation in the first place. I know that can be impossible sometimes, but I already built my own solution for fix this problem.
even though it's good to have, Github's UI doesn't help it, Github already sucks in terms of the review experience in a pull request and the implementation of the stacked PRs leaves a lot to be desired.
thankfully, I was working on my own solution for this problem and I already integrated a better stacked PRs implementation compared to github, and I'm pretty happy with it.
Pyor (pyor.review), I built it myself, sits on top of github, syncs everything with it, and gives me the benefit of having a better UI and code review experience.
even though it's good to have, Github's UI doesn't help it, Github already sucks in terms of the review experience in a pull request and the implementation of the stacked PRs leaves a lot to be desired.
thankfully, I was working on my own solution for this problem and I already integrated a better stacked PRs implementation compared to github, and I'm pretty happy with it.
Pyor (pyor.review), I built it myself, sits on top of github, syncs everything with it, and gives me the benefit of having a better UI and code review experience.