Graf Zahl wrote:Correction: It's not Github not working like that but Git not working like that.
A PR is nothing more than a work branch being asked to be merged back to the mainline, either by doing a real merge or a rebase. So any PR from some long running work branch will pull in all the changes that were made since branching off the mainline, i.e., it's not the commit being asked to be merged but the branch!
Yes - this is exactly right.
I think it's important to remember a distinction of what a commit really is for Git: each commit actually is its entire own unnamed branch (albeit in a frozen state), with complete history. That's why there's such a major difference between "git cherry-pick" and "git merge" - they might seem like they do the same thing, but they don't. "git merge" attempts to combine two histories together, where "git cherry-pick" intentionally tries to strip away a commit's history (and that's why a cherry-picked commit always has its own hash that's different from the commit that it came from).
This is important for multi-participant workflow because that allows multiple simultaneous projects to happen at the same time, for them all to eventually be merged in. It's what keeps Git from having a panic attack when you merge together 5 different 2000-commit branches, even when they touch the same files. (Yes, merge conflicts happen, but in an ideal world they'd be more rare than the ones we get in GZDoom - still though, people do deal with them)