Re: mixing a cherry-pick workflow with merge requests

[Simon McVittie <smcv@debian.org>]

On Mon, 18 Aug 2025 at 08:57:03 +0200, Marc Haber wrote:
> Additionally, is there a way to accept parts of an MR in Gitlab?

Not through the web UI, but you can `git cherry-pick` as usual, and then 
(ask the contributor to) rebase the rest. If you have a configuration in 
.git/config like this:

[remote "origin"]
	url = https://salsa.debian.org/utopia-team/dbus.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[remote "merge-requests"]
	url = https://salsa.debian.org/utopia-team/dbus.git
	fetch = +refs/merge-requests/*/head:refs/remotes/merge-requests/*
	tagopt = --no-tags

then the usual `git remote update` will fetch every MR for your 
inspection.

Github has essentially the same feature, but spelled differently:

[remote "origin"]
	url = https://github.com/flatpak/flatpak
	fetch = +refs/heads/*:refs/remotes/origin/*
[remote "pull-requests"]
	url = https://github.com/flatpak/flatpak
	fetch = +refs/pull/*/head:refs/remotes/pull-requests/*
	tagopt = --no-tags

When I'm doing upstream reviews (particularly during my day job where 
I'm more likely to be dealing with feature additions and a contributor 
who will be contributing again), I often suggest that contributors make 
a MR for uncontroversial preparatory work that can be fast-tracked 
(cleanups, minor fixes, extra test coverage for existing code, that sort 
of thing), and then a second MR based on that one for the more elaborate 
changes they were focusing on (which will often need more rounds of 
review, because it might need design changes).

    smcv