On Mon, Aug 18, 2025 at 09:47:03AM +0100, Simon McVittie wrote:
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.
Even the ones that are opened from a differnet repository?
And I would need to configure this for every repository I use, and
remember to have this configuration. I get about two merge requests a
month. Is that worth the hassle?
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).
At work, you can do that to a contributor. In Debian, I am reluctant to
talk to a patch submitter like I would talk to an apprentice or junior
rank colleague.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
