Can we merge stacks bottom-up?

[leoluk]

It looks like GitHub automatically changes the top PRs base branch when you merge a stack bottom-up (vs. top-down like we currently do):

This does not cause reviews to be dismissed like manually changing the base branch does:

I tested this using squash merges and it appears the merge is smart enough to ignore the "piled up" unrebased commits on the top PRs. Squash merging this one magically dropped the conflicting commit:

This worked just fine manually, so presumably we can do this automatically?

(example stack in question: https://github.com/certusone/wormhole/pull/892 - ignore the top one)

This might fix a number of issues with the current method:

• https://github.com/ejoffe/spr/issues/176 (no dismiss on auto rebase)
• https://github.com/ejoffe/spr/issues/175 (no more closing PRs, all are merged)
• https://github.com/ejoffe/spr/issues/98 (if it doesn't dismiss reviews, it might not re-check CODEOWNERS either)

[ejoffe]

I tried this approach initially, the issue I remember facing with this was that github actions for the next pr up the stack had to rerun after the bottom pr merged. But maybe I was doing something wrong, and it is possible to achieve. I'm not a big fan of merge commits, but if it solves this issue, I'm all for adding it as an option.

[wwade]

Does it play nicely with the new "merge" submit method, too (from #196)? I assume so, but worth double checking, too.

[leoluk]

I tried this approach initially, the issue I remember facing with this was that github actions for the next pr up the stack had to rerun after the bottom pr merged. But maybe I was doing something wrong, and it is possible to achieve. I'm not a big fan of merge commits, but if it solves this issue, I'm all for adding it as an option.

It doesn't require merge commits (but should work with merges, too). Actions did not re-run when I tested it, so perhaps that was fixed in the meantime?

[ejoffe]

If this work well, I am all for adding this as another merge option to spr. One more thing to watch out for is a race between github rebasing the pr and merging the next pr up the stack. I think you may have to poll the github api for the next pull request to make sure the base has been changed to master.

[ejoffe]

Closing this issue as no better way to merge a stack has been found to date. We might just have to deal with the approach of only merging the top pr in the stack. The plus side of this approach for us, is that we can run ci on each commit, but only run cd on each stack merge.