[kaashif]

I think a lot of people are anti rebase in general, but doing that on your own is fine IMO. I have a different issue.

The issue with is with rebasing multiple commits onto master instead of merging - the intermediate commits were never code that anyone ever actually wrote or tested, so any issues with them stem purely from the fakeness of the history.

If you have commit A then you write a branch A -> B -> C while someone else writes A -> D and they merge first, rebasing to get A -> D -> B' -> C' means B' was never something you wrote or tested. This code never existed on anyone's machine or had CI run on it before the rebase.

Does it really make sense to run CI on all of the new intermediate commits that rebase invented? What if some of those fail, are you really going to go through and fix tests for fake intermediate commits?

The solution for me has always been to squash. Inventing fake history is totally pointless and counterproductive. If you want cleanliness and bisectability via destroying the "real" history, just go ahead and really destroy it, don't invent a fake, possibly broken history.

[LegionMammal978]

I think the Rust project strikes a pretty good compromise for this issue: rebased linear branches with conflict-free merges onto master. When you make a PR, the CI sees whether your branch can be merged onto master without causing a conflict; if not, it directs you to rebase your branch onto the latest version of master. This check is repeated for all open PRs whenever the master branch is updated.

Once it's satisfied that your branch can be merged, it runs a subset of the tests, and throws an error if they fail. This way, even if you do rebase your branch, its latest commit will still be tested. (Having intermediate commits pass tests is encouraged but not required.) Finally, it regularly takes groups of 8 or so accepted PRs, tries merging them all in sequence, and runs the full test suite on the result. If it succeeds, the merge commits are pushed to master; if not, a human operator gets it to try again without the offending PR.

By your terminology, I suppose this would count as running CI on all the "invented" commits, and forcing PR authors to fix all their tests. But in practice, it's not too odious, since most PRs don't conflict (unless you're touching half the codebase), and any test failures from a non-conflicting change will get caught by the merge step.