Your use case is super weird. If you're going to do a --no-ff merge why would you rebase?
The merge commit acts as a kind of "pushlog"; it tells you what actually landed together as a single unit. It probably also tells you what passed CI; although many projects state that you shouldn't have individual commits that don't pass CI it's rare that this is enforced below the level of the PR. That should be good for bisection. Because the commits are always rebased onto master (and of course you never allow merge commits other than from code being integrated into master) your history is relatively clean, you don't get multiple overlapping branches, but something like
M1 ------- M2 -------- M3
\ B1 - B2 / \ C1 - C2 /
In principle this seems like the ideal way to use the tools git provides. However I understand there are some minor rough edges e.g. with magic needed to tell git bisect how to only try the merge commits.
Then was convinced even more after having to revert a ff merge.
Right, but what's the benefit of that? You still need to understand a history with merges in, in which case it seems like you might as well get the safety advantages of not rebasing.
Github also has protection to prevent branches from being forced, if you are only forcing a feature branch with no collaborators, or at the end of collaboration, it's not so bad, especially when git tells you the old hash you just overwrote and you have the reflog, but again github's rebase-then-merge should make that a non issue.
Surely there must be a way to tell git to show history in that form even with branches that haven't been rebased?
So does merging.
> or that conflicts have been fixed in the branch prior to the merge
Conflicts that show up in rebasing may not necessarily show up during a merge. Having to fix a bunch of conflicts that only occur because you rebased is tedious and introduces a source of potential error.
From an aesthetic perspective, rebasing and ff merging also destroys the history of what commit is related to what work branch.