On Tue, Aug 6, 2019 at 9:32 AM Micah Morton [off-list ref] wrote:

Unfortunately I didn't have the mental model quite right of what
happens during the pull request. I was thinking along the lines of my
commits being cherry picked onto your tree, rather than how it
actually happens with git merge where my tree's commit history needs
to match yours perfectly.

The "cherry-pick" model is what "git pull --rebase" does in reverse
(ie it pulls the exact history from the other end, and then rebases
the _local_ history on top of that).

But the cherry-picking model is entirely inappropriate for any bigger
project. Yes, you can do it locally on your _local_ small changes (but
see all the docs about why rebasing is not a great thing), but it's
entirely unmanageable and doesn't scale in the big picture.

It's why all the projects that were based on patch series were
complete and utter failures. A "patch series" only works locally. It's
not reasonable to scale and distribute.

Git fundamentally makes history a first-class immutable citizen, and
it's a major feature and a core design thing, and it's the _only_
thing that makes distribution possible. Whenever you rewrite history,
you fundamentally screw up a distributed model.

             Linus