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
