[rupertdenton]

This is a really interesting set of insights. I definitely see the theoretical benefits of stacking but as you indicate it feels like it requires a pretty good grip of git to manage. Do you have tooling to support with this in your team? To your last point, so let's say you've got 5 stacked PRs chained off of each other, you then need to merge master into each of them individually?

[travisb]

On a previous team we did create a wrapper command around git which did the parent-child branch tracking and added some convenience commands. On my current team we don't and it's OK because conflicting changes are rare so merging in from master is infrequently necessary and our code review tool can't make effective use of the extra stack information anyways.

Suppose you have the stacked PRs in the following sequence: A, B, C, D, E, F

If you implement stacked PRs using branches in git, then they will be a series of branches. For example, A will be a child branch of master, and B a child of A. To bring new changes in from master all the way down to F requires at least three commands and a build per stack member:

   git fetch
   git checkout A
   git merge master
   build_and_run_tests
   git checkout B
   git merge A
   build_and_run_tests
   git checkout C
   git merge B
   build_and_run_tests
   ...

Failure to do this for every PR in the stack tends to create confusing diffs in the code review system. For example, if you only merged the changes from master as far as C, then the code review system will probably try to show the diff between D and C:head which will contain the removal of a bunch of new master code. The code review really should be showing the diff between D and C:d_merge_base, but some code review tools don't support that and others need help, like the wrapper tool I mentioned previously.

[rupertdenton]

That's really interesting. So just so I understand the wrapper command automated those steps you've outlined? What were the convenience commands?

[travisb]

The wrapper was named "gut". I don't recall all the details so the names below are approximate. It wrapped the git command and added project-specific options (like --first-parent) to existing git commands, introduced new ones (like "gut check" which ran the build and tests), or hid native git command which were discouraged (like rebase).

"gut sync" merged in all the changes from the branch's parent into a single child branch, fetching if appropriate. We never got around to automating sequential syncing since the CI setup was weak in this project.

"gut create" created a new cascaded branch with the necessary tracking information from an arbitrary parent branch.

"gut review" posted the cascaded branch to the code review system so the diff would turn out correct.

"gut pdiff" would show the diff of the branch relative to the merge-base of the parent.

"gut reparent" would change the parent of a branch.

"gut insert" would insert a new cascaded branch between two existing branches -- useful for inserting refactors earlier in the series.

"gut merge" which merged the branch into the parent only once various checks, like review approval and passing tests and being at the head of the stack, were satisfied.