[atq2119]

The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges.

The approach that GitHub chose can show those people almost immediate benefits, which is surely the better path towards adoption than trying to reeducate everyone to adopt a development flow based on clean rebases.

And for those of us who do prefer clean rebases, the thing they built is still useful.

A bunch of details aside, the major conceptual thing that the email based flow has which is still missing in GitHub's data model is the ability to have a discussion on the stack as a whole.

[cube00]

> The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges.

We couldn't organise our commits once the PR review started because reviewers would complain they couldn't easily determine what had changed between rounds of reviews.

If we tried to organise them after review then approvals would be stripped so squash was the only way we could keep the main line history reasonably tidy as you can keep the approvals if GitHub does the squash via the UI.

[andrewaylett]

GitHub will now maintain approval if a rebase doesn't result in a changed diff. Small things :P.