I presume merge queues are useless if you have flaky tests?
Disclaimer: I'm the co-founder of Aviator
Merge queue builds should be fast and rock stable, following the 80/20 rule.
They’re a good justification to work on that tho.
It's hard not to think there should be some way of automatically flagging likely issues where, say, commits in one PR refer to particular identifiers that were modified in parallel PRs, but it definitely goes well beyond what diff-merge tools typically do today.
I agree that 90% of the time, with strongly typed languages, a compile is enough.
But even in those languages, you can still get semantic merge issues which aren’t compilation-related.
Suppose your app has a config file. The first PR renames one of the configuration keys in the config file, the second PR adds some new code which reads that configuration key. The combination compiles fine, but the second PR fails in integration tests, because the config key it was expecting wasn’t there any more.
Of course this is a sign of a design flaw - the name of the config key should occur only once in the program (say as a constant), so both PRs would use the constant, and the second PR would get the change in constant value from the first, or else the first renames the constant so the second doesn’t compile. Or even a higher-level API which deals with the semantics of what the config represents instead of just key-value strings.
But a lot of large legacy code bases contain design flaws like this, and fixing them can be a lot of work, so they don’t get fixed, at least not any time soon.