cc @Ekleog-NEAR this is an interesting case where merge queue setup fails spectacularly.

So originally I PRd a merge commit, pulling in bytecodealliance/wasmtime:main changes since the last fork. Then the merge queue "squashed" and "normalized" everything which caused this merge commit to instead become this humongous +100k,-100k commit. And now when I try merging again, it fails with a crapton of conflicts, because the only common base commit git sees with the bytecodealliance/wasmtime:main is the original base, and this +100k,-100k commit introduces a crapload of conflicts :D

@nagisa TBH I never understood why we squash-and-merge. This is already temporarily disabled on nearcore (because of the TOCTOU issue with reviews, see the bp issue thread on zulip), and it uses a merge commit there. I guess switching to merge commit everywhere might make sense for the reason you mention :)

TBH I never understood why we squash-and-merge.

Linear history in the main branch is pretty darn nice.

Linear history in the main branch is pretty darn nice.

I mean there’s git log --first-parent, git bisect --first-parent, and AFAICT basically all git commands have a way to ignore the branches and treat the merges as though they were squash-merges