Partially merged MRs, or, patch-based workflows
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.
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
What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?
Who is this for? Provide one or more use cases.
Make sure these are completed before closing the issue, with a link to the relevant commit.