Skip to content

Partially merged MRs, or, patch-based workflows

Description

It's common for a merge request to be organized into several commits: preparatory work first, then the addition of a new feature later. The git log might look like:

00000000 Scary New Feature frontend
aaaaaaaa Scary New Feature backend
bbbbbbbb Refactor something
cccccccc Fix a bug in X

As an MR goes through review, those earlier commits get refined and eventually are in a state where we want them in master, but they're blocked from being added until the whole MR is complete.

Proposal

Allow a reviewer to specify that commits up to X are done. This merges just those commits to master immediately, and so removes them from consideration for the rest of the MR's lifetime. In the example above, the maintainer could approve cccccccc..bbbbbbbb in the first round, aaaaaaaa in the nth round, and then 00000000 several rounds after that.

We can do this manually at the moment by cherry-picking the commits into a separate branch, creating an MR and having it reviewed and merged. However, I rarely do this as it's a lot of administrative overhead when the code is going into master anyway.

Links / references

Documentation blurb

Overview

What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?

Use cases

Who is this for? Provide one or more use cases.

Feature checklist

Make sure these are completed before closing the issue, with a link to the relevant commit.

/cc @smcgivern @victorwu