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-tagsthen 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