Document branch and repo settings requirements

[palves]

On my company's github.com repos, when spr changes the target of a PR, e.g., because you've merged the bottom patch of the series, and the next PR is now the bottom one, github.com invalidates existing approvals.

I would be great if the spr documentation explained what are the ideal github branch protection rules and repo settings so that it works to its full extent.

I thought that the losing approvals when the base changes was hardcoded on github.com nowdays. See:

https://github.com/orgs/community/discussions/147779
https://github.com/orgs/community/discussions/57513
https://github.com/orgs/community/discussions/57944

... where we find plenty of people talking about this. The last one for instante is exactly about this github issue with stacked PRs.

It seems like people have been happily using git spr regardless, so I think I'm missing something. And I think it'd be great if that something were documented! :-)

Thanks a lot for git spr, btw. I've been experimenting with it on and off for a while, even have patches that I plan to submit eventually, but this issue is a major blocker.

[ejoffe]

My guess is that 95% of the time people merge the whole stack and then this is a non issue.
One idea to mitigate the partial stack approval removal might be with a bot that reapplies the approval in this case.

[palves]

I'm confused -- to merge the whole stack, spr changes the target branch of the top PR to be against the final target branch, instead of against the next PR in the series. That target branch change should drop the approvals, just like the case in the PR description. No? Is there something different in that merge that I'm missing?