It isn't arbitrary. A branch is the unit of change. You can stack branches on top of each other and merge them one at a time. You can also keep adding to the end of the stack as needed.
I understand that GitHub kinda ate the world on this, but using a branch PR as the basic unit of change seems like an arbitrary choice to me.
Torvalds invented Git for work on the Linux kernel, and the basic unit of change there is commits over email. It's not uncommon for them to take some commits but reject others.
Which isn't meant to say "pull requests are obviously wrong and commits over email are obviously correct", but rather to point out that the idea of a take-it-or-leave-it branch isn't some kind of natural unit of contribution
> Git for work on the Linux kernel, and the basic unit of change there is commits over email. It's not uncommon for them to take some commits but reject others.
After reading this article[0], it's become clear to me that what you want is a reference branch, which people propose changes to. Then there's the integration process that takes a unit of change (commit or PR) and then tests that the reference branch is <good> after applying that change. If it's not, then that unit of changes is sent for rework. If it is, it's now become part of the reference branch and the next units of change needs to be able to work together with it.
In corporate work, I tend for the PR to be the unit of work, which means squashing and merging. But any PR is compared to the default branch, not each other. Anything that is not yet part of the default branch, even if approved, is unreliable. So as the author, you'll need to refresh your PR to not rely on an old state of the reference branch.
I think there is too much focus on the PR itself instead of the reference branch which reflect the true state of the next release. Like their PR was good at the time of writing, so it should be merged. Instead of whether merging their PR would break the reference branch.
Torvalds invented Git for work on the Linux kernel, and the basic unit of change there is commits over email. It's not uncommon for them to take some commits but reject others.
Which isn't meant to say "pull requests are obviously wrong and commits over email are obviously correct", but rather to point out that the idea of a take-it-or-leave-it branch isn't some kind of natural unit of contribution
https://lkml.iu.edu/hypermail/linux/kernel/1402.2/00508.html
https://lkml.indiana.edu/2011.2/05416.html
https://lkml.iu.edu/2409.0/00960.html
https://lkml.iu.edu/hypermail/linux/kernel/2510.3/01369.html