[leghifla]

On the other hand, rebasing can create its own problems re: regression finding

If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter.

So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...

[yakubin]

That’s why at work we have a “commit queue” that tests that every commit builds as it comes in in the order it’s merged (or more accurately: cherry-picked). Don’t leave those things to manual checks and human vigilance. They’re too fallible.

[the_gipsy]

I think this can be mostly worked-around by requiring branches (PRs) to be rebased and tested/CI-passed before merging.

If PRs contain multiple commits, either squash them (on merge or before), or use some kind of queued / stacked PR system.