# Testing merge requests
**URL:** https://discourse.vtk.org/t/testing-merge-requests/2947
**Category:** Dashboards
**Created:** [April 3, 2020, 12:41am UTC](https://discourse.vtk.org/t/testing-merge-requests/2947 "2020-04-03T00:41:58Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@utkarshayachit](https://discourse.vtk.org/u/utkarshayachit)
#### Post date: [April 3, 2020, 12:41am UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/1 "2020-04-03T00:41:58Z")
should we recommend use `Do: test --merged` when testing older branches esp. those that are being backported to the release? I suspect that is one the reasons why dashboards are taking too long of late.
---
### Author:  [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)
#### Post date: [April 3, 2020, 1:27am UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/2 "2020-04-03T01:27:55Z")
That should improve testing turnaround time, I think.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 3, 2020, 11:49am UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/3 "2020-04-03T11:49:36Z")
For backported branches, yes. Basically anything older than 100 or so commits would probably benefit from it.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [April 6, 2020, 7:06am UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/4 "2020-04-06T07:06:33Z")
Tbh we may want to make it the default and add a command to actually run as not-merged for the odd cases where it may be necessary.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 6, 2020, 1:37pm UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/5 "2020-04-06T13:37:45Z")
The logic for `--merged` is in [this repo](https://gitlab.kitware.com/utils/ghostflow-director/). Please file an issue.
Note that one downside to `--merged` is that buildbot now no longer knows your source branch name in the `buildbot.kitware.com` grid (it is `refs/test/release/6629/heads/1` where 6629 is the MR number and `1` means it is the second merge-test of the MR). CDash has the real name though.
I’ll note that gitlab-ci does not run merged tests by default for MR testing. We’d need `Do: test` to interact with gitlab-ci first (nb. we need that anyways for `Backport` testing too).
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [April 6, 2020, 11:51pm UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/6 "2020-04-06T23:51:06Z")
Though this might be slightly off-topic, I’m wondering exactly what “Backport: release” does.
Does it simply merge the MR into release, and then merge release into master?
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [April 7, 2020, 3:46am UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/7 "2020-04-07T03:46:51Z")
[https://gitlab.kitware.com/utils/ghostflow-director/-/issues/66](https://gitlab.kitware.com/utils/ghostflow-director/-/issues/66)
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 7, 2020, 12:23pm UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/8 "2020-04-07T12:23:37Z")
> [@dgobbi](#):
>
> Though this might be slightly off-topic, I’m wondering exactly what “Backport: release” does.
>
> Does it simply merge the MR into release, and then merge release into master?
Not quite. It merges the MR HEAD commit into the target branch, any backport branch gets the same. So you get a graph that looks like this:
```auto
-- M - M - M (master)
/ /
T /
/ \ /
-- R - R (release)
```
Where `T` is merged independently into `master` and `release`. As part of making `release` always reachable from `master`, there is then a `git merge -s ours release` done on `master`. This is then pushed all-as-one to the main repository using `git push --atomic`.
Note that `T` might be different for each backport target branch from a single MR (e.g., `Backport: release:HEAD^2`) which is why, in general, separate merges are necessary (rather than merging once then cascading the branches together via merges that way).
Various branch/MR topologies for different situations: [https://gitlab.kitware.com/utils/git-workflow/-/wikis/Backport-topics](https://gitlab.kitware.com/utils/git-workflow/-/wikis/Backport-topics)
Implementation of the logic to do the backports: [https://gitlab.kitware.com/utils/rust-ghostflow/-/tree/master/ghostflow%2Fsrc%2Factions%2Fmerge](https://gitlab.kitware.com/utils/rust-ghostflow/-/tree/master/ghostflow%2Fsrc%2Factions%2Fmerge)
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [April 7, 2020, 3:40pm UTC](https://discourse.vtk.org/t/testing-merge-requests/2947/9 "2020-04-07T15:40:59Z")
Thanks, Ben, that wiki page on backports clears things up a lot. Nice contribution.