Show stacked merge request relationships in the merge request UI

Show merge request chain relationships in the UI

Summary

When a series of merge requests are chained together — where MR A targets MR B, MR B targets MR C, and MR C targets main — GitLab has no way to surface that relationship in the UI. The chain is implicit in the branch structure, but a developer or reviewer looking at any individual MR has no in-product signal that it is part of a larger sequence.

Problem

Chained merge requests are a natural outcome of breaking large changes into smaller, independently reviewable pieces. A developer working on a complex feature might open several MRs where each one builds on the previous, targeting the prior MR's branch rather than main directly. This is a valid, common pattern — but GitLab's UI treats each MR as an island.

This creates real friction:

For authors:

  • There is no way to see the full chain at a glance from any individual MR. You have to know the branch structure and navigate manually.
  • There is no indication of where a given MR sits in the sequence — whether it is the first, somewhere in the middle, or the last before the base branch.

For reviewers:

  • A reviewer on MR B has no in-product context that MR A depends on it, or that MR C came before. The diff they are reviewing may only make sense relative to adjacent MRs in the chain.
  • Without chain context, it is harder to prioritize, sequence reviews, or navigate to related changes.

For everyone:

  • The relationship that exists in the branch structure is invisible. Teams working this way carry the mental overhead of tracking chain order entirely outside of GitLab.

Why this matters now

The industry is converging on code review as the primary bottleneck in modern software delivery. AI coding tools are accelerating code authoring faster than review capacity can absorb, and the response — both in tooling and in practice — is to keep individual changes smaller and more focused. Chained MRs are one of the most effective strategies for this: rather than one large MR, a developer produces several smaller ones that can be reviewed independently and in parallel.

The pattern is gaining adoption broadly, and the expectation that a code review platform surfaces chain relationships is becoming baseline.

GitLab already has all the underlying data needed to detect these relationships — they are encoded in source and target branch connections between MRs within a project. The gap is purely at the UI layer.

Opportunity

The most minimal useful change here is simply making the chain visible. When an MR is part of a chain, show it. No automation, no rebase tooling, no workflow changes — just a clear, lightweight indication of the relationship so that authors and reviewers have the context they need without leaving the MR view.

This would reduce the cognitive overhead of working with chained MRs, make GitLab's review experience more legible for teams already using this pattern, and lay the foundation for deeper capabilities if the workflow proves to be in demand.

Out of scope for this issue

  • Automated rebase or merge sequencing
  • Any changes to how MRs are created or branches are managed
  • CLI integrations or tooling changes
  • Any workflow beyond surfacing the relationship that already exists

References

  • Community MR !184846 (closed): prototype implementation surfacing stack relationships via GraphQL and a Vue widget
  • cli#7473: User feedback thread with demand signals for this visibility
Edited by 🤖 GitLab Bot 🤖