[magicloop]

I think that is 2/3 of the story. The other 1/3 is the "patch" workflow.

In linux kernel development, it is all about sending patch sequences to a mailing list, comprising well-crafted logical steps. Then the maintainer applies the changes. This side-steps the rewrite merge history problem.

This is, I argue, what the default workflow was supposed to be, as the workflow came out of the LKML working practices in developing git.

The way I see it from a project scaling perspective, the patch based workflow is the most scaleable. Written another way: patches > rebase > merge

I think it also gives the best change history, again patches > rebase > merge

Pull Requests were really a GitHub thing. I like them. I wish people made the best out of them. When they do the atomic change to the trunk, it is worthwhile using a hand-crafted meaningful message explaining the goals, and reasons for making the change, together with a terse heading sentence ahead of the detail. Why many people advocate for rebasing for clean history, but leave a trash default-created PR merge commit message has always puzzled me.