On Tue, Aug 6, 2019 at 9:32 AM Micah Morton <mort...@chromium.org> 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