Intent-aware fork sync: re-apply downstream patches and propagate security fixes across a fork network

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

Self-managed customers and open-source downstreams routinely run modified forks of GitLab and of the projects they host. Those forks carry private patches: a custom auth hook, a rate limit, a UI tweak, a compliance check. Every time upstream moves, someone has to hand-rebase those patches. When a function they touched is renamed, a file is split, or a module is rewritten, the existing "Update fork" flow fails with conflicts and the work becomes manual.

Two consequences follow. First, forks fall behind, because re-porting patches is the hidden cost of every upgrade, and that is one of the reasons self-managed instances sit on old versions. Second, security fixes do not reach the forks that need them. When upstream ships a patch release, the modified forks are the ones that lag, and the fix already exists.

Today GitLab knows a fork is behind (divergence counts, fork sync) but cannot help with the part that actually costs time: carrying the fork's own changes forward across upstream refactors.

Proposal

Extend fork sync so that a fork's own commits are treated as patches with an intent, and so that when a plain merge or rebase fails, GitLab produces a merge request in the fork with the patches re-applied against the new upstream, rather than a failure. Delivered as small, independently useful pieces:

  1. Patch inventory. On the fork's divergence view, list the commits the fork carries ahead of upstream as distinct patches, using each commit or MR description as its intent summary, and show which ones would conflict with the current upstream via a dry-run rebase. No AI involved; pure git plumbing on top of the existing fork-sync service.
  2. Conflict-to-MR. When "Update fork" would fail, create a merge request in the fork containing the attempted rebase with conflicts, instead of aborting. This alone turns a dead end into a reviewable artifact and reuses the existing conflict-resolution UI.
  3. Intent-aware re-application. Trigger the existing "Resolve with Duo" merge-conflict flow on the fork-sync MR, extended so each conflicted patch's intent summary and original diff are passed as context. Patches Duo cannot resolve confidently are labelled as needing manual attention rather than guessed at. The agent proposes; a human merges.
  4. Security propagation. When an upstream merge request carries a security label, forks that have opted in get a sync MR raised automatically with that change, going through steps 2 and 3 when it conflicts. This is fork-side pull, never upstream push, so upstream never gains access to a fork.

Everything is behind a feature flag the group names, and every action results in a merge request; nothing is ever pushed to a protected branch.

Intended users

Self-managed administrators maintaining a modified GitLab instance; platform teams that maintain internal forks of upstream projects hosted on GitLab; open-source maintainers who want their downstream forks to stay current and patched.

Feature usage metrics

Count of fork-sync MRs created, split by whether they were clean, conflicted-only, or Duo-re-applied; merge rate of Duo-re-applied MRs; time from an upstream security MR merging to the corresponding fork MR merging.

Proposed delivery order

Each step as its own MR against master, behind the feature flag:

  1. Patch inventory service and API, mirroring the existing fork-sync and divergence services.
  2. Divergence view UI for the inventory.
  3. Conflict-to-MR in the fork-sync flow.
  4. Invoke "Resolve with Duo" on fork-sync MRs with patch intent as context, with the "needs manual attention" label path.
  5. Security-label propagation for opted-in forks.
  6. Documentation.

Out of scope for the MVC: cross-instance fork networks, automatic merging of any kind, and forks whose history cannot be decomposed into patches (these fall back to the plain conflict MR).

What I would need from GitLab

  • A maintainer from the Source Code group to sponsor the design, say yes or no to the scope above, and tell me what to cut.
  • Confirmation on whether to build on the existing fork-sync service (Projects::Forks::SyncService) or alongside it, and the feature flag and rollout approach the group wants.
  • For step 4, a contact from whichever group owns the "Resolve with Duo" conflict flow (group::dap repository flows or group::code review), and a Duo-enabled development instance, since that step cannot be developed against a plain GDK. I understand community contributors can be granted Ultimate and Duo access for this purpose.
  • A quick permissions review of step 5 before I build it, to confirm the fork-side pull model is the right boundary.
  • A reviewer I can tag on the MRs, and a UX check on the divergence view for step 2.

I would deliver it in the order above rather than as one large MR, and would start with steps 1 and 2, which have no AI dependency and are useful on their own.

Links / references

  • #429030 covers automatic sync when there are no conflicts; this proposal is the complementary case, when there are. The two compose.
  • #540409 asks for scheduled sync with conflict notification; this proposal turns the notification into an actionable merge request.
  • The existing "Resolve with Duo" merge-conflict flow is the building block for step 4; the new part is invoking it on fork-sync MRs with the patch's intent as context.
  • #605189 (agentic breaking-change resolution after dependency bumps) is the same shape of problem applied to a different kind of upstream change, and is the precedent for the human-merges, agent-proposes model used here.
  • #607061 (closed) (backport-aware Duo Code Review) shows the same intent-of-the-original-change framing already being applied to backports.
  • Security-fix propagation to downstream forks (step 5) has no existing issue.

About me

I have been contributing fixes across gitlab-org/gitlab and several sibling projects (gitaly, gitlab-shell, glab, omnibus-gitlab, charts/gitlab, the AI gateway) and am comfortable in the Rails codebase and shipping work as small reviewable MRs. Much of that work involved rebasing onto a moving master and re-applying changes across refactors by hand, which is the problem this proposal automates. Profile: https://gitlab.com/sjestonsingh

Edited by 🤖 GitLab Bot 🤖