This is why I follow a rebase-then-merge approach. The commit graph looks like this:

   |
   *
   |\
   | *
   | |
   | *
   |/
   *
   |\
   | *
   |/
   |

Each PR is neatly delineated, and I can quickly follow things at coarse-grained level (follow only the left parents; there's even a `git log` flag for this) or at a fine-grained level.

This isn't just pretty -- this has been actively helpful to me many, many times. I can `git bisect` into a merged PR to more precisely identify where an issue arose, and `git rebase` onto intermediate commits instead of jumping all the way to the end if I find a whole PR to be problematic to rebase past in one go.

Semi-linear merge is my favourite too. I'll also often reset soft and hand craft the commits for the PR to lay out the work of the branch so that it builds up logically, and assist reviewers (and future-me) in understanding the structure of the change.

I also try to adopt this approach whenever possible. The 'git log' flag you mention is '--first-parent'.

Thanks for mentioning the specific flag! I didn't mention it because I don't use it often enough to remember it (the shape of the log is usually enough), but it does exist if you want it :D

I also enjoy waiting for unnecessary pipelines to run again, because we must first rebase. ;-)

It's XKCD's "My code's compiling!" for 2022.

It's a tradeoff. I've been in multiple situations where two branches independently work fine at runtime, and merge without conflict, but the merge is broken at either compile-time or runtime. I'd rather rebase with cognizance over what I'm rebasing over, and make sure my changes are actually semantically consistent afterwards.

Of course, if you have an organization-wide monorepo, this isn't going to work. (At the same time, at that point, you should probably be a bit more selective about what CI you run based on what components have changed... and make decisions about what checks to run nightly rather than on PRs.)