### Summary When using a merge train heavy workflow, where 15-20 minutes are spent for each merge train, final squash failures are extremely costly and difficult to predict or avoid. The "squash-and-merge" strategy appears to effectively replace the source branch with a single version commit immediately before merging. This erases the history of the branch, including any merge bases created between when the original source branch was created and when "squash-and-merge" occurs thereby significantly decreasing the likelihood that the 3-way merge algorithm can perform the merge without a conflict. The strategy does not appear to be tested before running the merge train pipeline which often results in an extensive pipeline run which succeeds but ultimately causes merge train restart when squash-and-merge fails. When this occurs, the message `Squashing failed: Squash the commits locally, resolve any conflicts, then push the branch` is appended to the MR. There do not currently appear to be any solutions other than "don't use squash-and-merge with merge trains" or "have all devs locally squash and force push". ### Steps to reproduce Create a new repo with one feature branch. Make changes that will cause a conflict if and only if the MR is squashed-and-merged. Start a merge train. ### What is the current *bug* behavior? Squash-and-merge causes merge failure _after_ merge train pipeline succeeds. ### What is the expected *correct* behavior? Squash-and-merge should fail _before_ merge train pipeline starts. #### Results of GitLab environment info SaaS Premium ### Possible fixes Don't use heavy merge train pipelines or don't use squash-and-merge.