Stacked Pull Requests | GitKon 2022 | Tomas Reimers, Graphite

This is such a simple solution to a problem I've had for a long time. Thanks for the clear and well-prepared video!

we got 99 issues and my branch ain't one

Great idea but this is already possible with rebasing. Rebasing may incur some headaches but most of that can be avoided with good communication amongst teammates.

"Stacking lets you make many small PRs easily, and without having to wait for review." I don't need a tool to do that right? I can just make small PRs.

IMO, to complete the picture, a comparison to trunk-based development is missing in this video. I agree that asking to review massive PRs is very expensive for everyone. However, I'd argue that big PRs are symptoms of a bigger, often organisational problem. If I understand correctly, you are proposing a tool that runs a series of rebases automatically. But I think the main problem is the fact that we need to start a PR in the first place. So, I'd say there are two approaches to working on a single codebase as a team: trunk-based and some sort of branching strategy. I think you need to expand on this one.

As a side note, the bigger issue is that many engineers don't understand what rebase does, and why merging 'main' into a 'branch' is <use your adjective here>. So, I'd say start there first.

What is this terribly inefficient format of a presentation? Just get to it...

Having worked with stacked PRs at meta for 3 years, then moving to a company that doesnt have it, my productivity seemed to halt. Stacked PRs is one of those things where you dont realize just how incredibly powerful it is until you've used it and its taken away. Good job guys!

What is actually the difference between this and just managing feature branches?

All this complexity because you needed someone to review your PR but the team is too busy, possibly due to high work in progress (WIP)
This is exactly the opposite of lean, adding more PRs will increase your WIP that inevitable will make all PRs slower and those you need to review too
It may feel like your are going faster but I encourage you compare your deployment frequency if you don't stack.

An alternative solution would be for the team to reduce your collective WIP and leave slack capacity for timely reviews