What is the difference between Merge Train and Merge Result in GitLab

You can check out the article "How merge trains keep your master green" from Orit Golowinski

Merge trains introduce a way to order the flow of changes into the target branch (usually master).
When you have teams with a high number of changes in the target branch, this can cause a situation where during the time it takes to validate merged code for one change, another change has been merged to master, invalidating the previous merged result.

(Note: Merge Train was originally proposed in gitlab-org/gitlab-foss issue 4176, then moved to gitlab-org/gitlab issue 3709)

By using merge trains, each merge request joins as the last item in that train with each merge request being processed in order.
However, instead of queuing and waiting, each item takes the completed state of the previous (pending) merge ref (the merge result of the merge), adds its own changes, and starts the pipeline immediately in parallel under the assumption that everything is going to pass.

If all pipelines in the merge train are completed successfully, then no pipeline time is wasted on queuing or retrying.
Pipelines invalidated through failures are immediately canceled, the MR causing the failure is removed, and the rest of the MRs in the train are requeued without the need for manual intervention.

An example of a merge train:

• MR1 and MR2 join a merge train.
• When MR3 attempts to join, the merge fails and it is removed from the merge train.
• MR4 restarts at the point that MR3 fails, and attempts to run without the contents of MR3.
• MR3 will remain open in failed state, so that the author can rebase and fix the failure before attempting to merge again.

This differs from Pipelines for Merged Results (only in GitLab Premium 11.10., Apr. 2019, in issue 7380)

When you submit a merge request, you are requesting to merge changes from a source branch into a target branch. By default, the CI pipeline runs jobs against the source branch.

With pipelines for merged results, the pipeline runs as if the changes from the source branch have already been merged into the target branch.
The commit shown for the pipeline does not exist on the source or target branches but represents the combined target and source branches.

The problem those pipelines solve is:

Teams need to keep master "green".

It's a huge pain when someone merges a MR that breaks master because they didn't know of some conflict and their MR's pipeline was green.
It's great that master has its own pipeline with tests so it won't accidentally deploy a broken codebase, but it's not nice that master is left broken, and any MR based on master will now fail as well.

If we had a way to build the combined result of the merge before merging, it would go a long way towards being more confident in the result.

Regarding the reasoning for having a new pipeline as explained by @VonC It seems to me that using the merge train commit in the master branch is merely a matter of book keeping for gitlab along with an additional git operation. If I understand correctly there is essentially no diff between the commits in the merge train commit and the merge results commit.

To me, it feels that this can be achieved with two separate steps

1. Once a merge train pipeline passes, essentially the master branch needs to be reset to the merge train commit (a git operation)
2. And the merge train pipeline should also become associated with the master branch (gitlab internal bookkeeping operation)

Since both these operations will only happen if the pipeline passes, the master branch will always be green and at the same time, we could avoid a possibly expensive and unnecessary pipeline run for a new merge results commit. Not sure if I'm missing something or have understood this incorrectly